The Intuit Payroll Phish That Quickbase Delivered

The sending address was notify@quickbase[.]com. Not a spoof of it. Not a character-swapped imitation of it. The actual notification mailbox that Quickbase uses to tell customers something happened inside one of their applications, carrying a payroll payment confirmation branded end to end as Intuit.

The first tell sat in the HTML. The body declared a base href of hxxps://intuitcorp[.]quickbase[.]com/db/, and the Intuit logo at the top of the message was pulled from hxxps://intuitcorp[.]quickbase[.]com/up/[app-id]/g/ri/eg/va/NewIntuitLogo[.]png. That is not Intuit infrastructure. It is a Quickbase application subdomain, provisioned by the attacker and named to read as an Intuit corporate property.

The second was a typo the attacker never saw. The notice told the recipient that Intuit had successfully received payment for [client company] in the amount of $1,799.95 for the payroll dated empty. The word empty rendered in italics, in the body, in front of the customer, precisely where a date was supposed to merge in. The kit had a null value and printed it.

The target was a mid-size CPA and accounting firm, which reads real payroll notices all day and reacts fast to a payment exception.

A Real Quickbase Tenant, Dressed as Intuit

The low-code SaaS playbook here is short. Sign up. Create an application. Upload a logo. Let the platform's own mail system do the sending.

What the attacker buys is not the app. It is the hostname and the relay behind it: a subdomain on a reputable vendor domain, with valid TLS, no registration age to hold against it, and no blocklist entry, because blocking it would mean blocking every legitimate customer on the shared domain. Read quickly, intuitcorp[.]quickbase[.]com scans as an Intuit corporate workspace, not a stranger's project.

The base href deserves its own note, because it is the piece most triage workflows never open. In HTML mail, that declaration sets the root every relative URL resolves against, so the images, and any relative link, silently resolve to attacker infrastructure. A body that appears to hold no hostile links can still be reaching a host the attacker controls.

Which matters, because the only absolute links here pointed at genuine Intuit content: a real community article and a real QuickBooks support page on resolving a non-sufficient-funds hold on payroll. Working links, chosen to give the payment story a paper trail. A scanner walking that body finds Intuit, Intuit, and a Quickbase subdomain, all resolving.

That combination maps to MITRE ATT&CK T1583.006, Acquire Infrastructure: Web Services for the rented tenant, T1656, Impersonation for the brand costume, and the delivery itself to T1566, Phishing.

The Merge Field That Told On the Attacker

The empty string is more than a joke. It is evidence about how the message was built.

A template with variables means a system built for volume: a recipient list, a data source, and fields expected to fill per target. One field came back null and the renderer printed the null. The same subject line later resurfaced against additional mailboxes at the same organization, which is campaign infrastructure, not a one-off.

The pretext repays a close read. This is a confirmation, not a demand: a payroll payment succeeded, for a client and an amount the recipient never authorized. Nobody has to click anything for that to work. The intended reaction is a fast, alarmed reply asking what this charge is, the same instinct that drives business email compromise losses. The 2024 Verizon Data Breach Investigations Report puts pretexting, largely BEC, at the top of the social engineering category, with a median transaction near $50,000.

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

Why Every Authentication Check Came Back Green

The header block is the reason this landed in an inbox.

SPF passed, with the connecting relay at 156[.]70[.]3[.]206 and an envelope sender domain of qbmailbounces[.]quickbase[.]com, the bounce domain Quickbase uses for transactional mail. The Received chain traced back to 3[.]128[.]229[.]235, a cloud host announcing itself as Quickbase. DMARC passed, because that envelope domain aligns under relaxed alignment with the header From domain quickbase[.]com. Composite authentication returned a full pass.

Exactly one check failed. DKIM reported a body hash that did not verify against the signature for quickbase[.]com, meaning the body changed after the platform signed it. It is also the one signal almost nobody enforces alone, because benign mail mangling breaks body hashes often enough to make alerting noisy. SPF alignment carried DMARC to a pass regardless.

This is not an authentication failure story but an authentication success story, working as specified. DMARC answers a domain-level question, and here the honest answer was yes. It was never built to say whether the content is truthful, and the NIST definition of phishing turns on deception of the human reader, not the envelope.

The Reply Path That Went Nowhere

The Reply-To address was set to urgentpayrollissue@intuit[.]com, and the sender string rendered as urgentpayrollissue @ intuit[.]com (via Quickbase).

That address is at the real intuit[.]com. It is not a character-swapped imitation domain, and the attacker does not run Intuit mail, so a panicked reply would bounce or land in Intuit territory rather than reach the operator. Paired with the unfilled merge field, it is a second tell that this campaign shipped without a test send.

What it does accomplish is visual: many clients surface the alias over the address behind it, so a recipient skimming the header reads intuit[.]com twice and quickbase[.]com once, both real companies.

Confidence in the Middle, Verdict From a Human

Themis, the IRONSCALES Adaptive AI analyst, scored this in the middle of its range at 59% and flagged the recipient as a high-value mailbox. A human analyst confirmed the verdict.

That middling score is the honest outcome here. There was no malicious attachment, no credential form, no freshly registered domain, no failing authentication to anchor a high-confidence call. What was left were relationships: a platform domain the organization had never heard from, a brand mismatch between envelope and body, and financial language about a payment nobody made.

What to Actually Do

Treat SaaS notification senders as their own trust class: trusting a platform your organization uses is not the same as trusting every brand painted inside the mail it sends.

Alert on brand mismatch, where the body impersonates one vendor while the envelope belongs to another, and inspect the tenant name on shared SaaS hostnames, because a subdomain spelling a different company's brand is a strong indicator by itself. Parse the base href and image sources during triage, not just the visible anchors, and add template artifacts to your content rules: bare empty or null values and unrendered variable syntax. The CISA phishing guidance makes the same structural argument for layered, behavior-aware controls, because no single authentication or reputation check survives an attacker who rents the reputation.

Indicators of Compromise

The Bottom Line

Authentication told the truth and the message was still a lie. When an attacker rents a trusted vendor's sending infrastructure, the header block stops being evidence of intent, and what remains is behavioral: has this domain ever written to us, and does the brand in the body match the envelope that carried it. A broken merge field answered the second one. Do not count on the next one being this sloppy.