NetSuite Sent the Invoice. Oracle Signed It. The Payment Token Was the Weapon.

The invoice arrived from a legitimate NetSuite account, signed twice by Oracle infrastructure, and pointed to a real payment portal with a pre-filled token. SPF passed. DKIM passed (dual signatures from sent-via[.]netsuite[.]com and nrt1[.]rp[.]oracleemaildelivery[.]com). DMARC passed. The only question left is one authentication cannot answer: was this invoice real?

Oracle's Infrastructure Did Exactly What It Was Designed to Do

The email was sent from system@sent-via[.]netsuite[.]com on behalf of "Finance QIMA/WQS" with a Reply-To of finance@wqscert[.]com. It was relayed through Oracle Email Delivery from a Japan datacenter (aib29dd127[.]nrt1[.]oracleemaildelivery[.]com, IP 192[.]29[.]44[.]127). The X-NetSuite headers confirmed this originated from within the platform: compId=4552646, search=664953, owner=2859289.

This is EaaS (Email as a Service) abuse at its cleanest, and a textbook example of why phishing detection cannot rely on authentication alone. The attacker did not spoof NetSuite. They used it. Whether through a compromised QIMA account or a fabricated invoice created directly in the platform, the sending chain was entirely legitimate. Microsoft's own anti-spam engine assigned SCL=9 with SFTY:9.25, an unusually aggressive score for a message with perfect authentication. That tension between full auth passage and high spam scoring reflects how conflicted static analysis becomes when infrastructure trust and behavioral signals diverge.

A Payment Link That Scans Clean Because It Is Clean

The "Click and Pay" CTA linked to my[.]qima[.]com/pay-pre-filled/qimawqs/a0d9464fe506416497b71c4ea7776c18. That is a real QIMA payment portal with a pre-filled token. The URL scans clean because the domain is legitimate and the page functions exactly as designed. The invoice fraud payload is not a credential harvester or a malware dropper. It is a real payment form, pre-loaded with an invoice the attacker wants paid.

The email also included links to qima[.]com/terms-and-conditions and qima[.]com/contact-us, further reinforcing legitimacy. The subject line referenced a specific invoice number and named both the buyer and the vendor. The target was an employee at a food and beverage company.

Behavioral Signals Were the Only Detection Surface

Themis, the IRONSCALES Adaptive AI, classified the message as Invoice Phishing at 63% confidence. The detection was not based on a malicious URL, a bad signature, or a known threat indicator. It was based on sender relationship analysis: the recipient had no established communication history with this NetSuite-generated sender identity. Four mailboxes were quarantined.

The open question for incident responders is whether the QIMA NetSuite account was compromised (account takeover) or whether the invoice was fabricated within the platform by an authorized user (insider or social-engineered access). Either scenario produces the same result: a fully authenticated, infrastructure-clean invoice that only behavioral analysis can flag.

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

Indicators of Compromise

MITRE ATT&CK Mapping