Oracle Email Delivery Sends the Phish: Authenticated Invoice Lure via NetSuite Infrastructure

The body of the email was a single paragraph: "Please open the attached file to view your Quote. To view the attachment, you first need the free Adobe Acrobat Reader." It included a link to an HTTP version of Adobe's download page, a URL format that Adobe itself deprecated years ago. No quote number. No line items. No pricing. No sender phone number or signature block. Just an instruction to open the PDF.

The email arrived from [user][@]hillas[.]com via Oracle Email Delivery infrastructure (baf146cc130.iad1.oracleemaildelivery.com, IP 216[.]146[.]33[.]130). SPF passed. DKIM passed for both the sender domain and Oracle's delivery signing domain. DMARC passed. The Reply-To field pointed to a NetSuite-format transactional address at 3728588.email.netsuite.com, the kind of address that accounts payable teams at organizations using NetSuite would recognize as familiar.

This was a first-time sender. No prior correspondence existed between the sending address and the target organization, a specialty ingredients manufacturer.

Legitimate Infrastructure, Illegitimate Intent

Oracle Email Delivery is a transactional email service within Oracle Cloud Infrastructure. Businesses use it to send invoices, order confirmations, and automated notifications through NetSuite and other Oracle products. When a domain owner configures Oracle Email Delivery as an authorized sender, Oracle's servers are added to the domain's SPF record and DKIM signatures are applied. The result: any email sent through the service passes authentication checks as if it came directly from the domain owner.

This is exactly what makes the platform attractive for abuse. The attacker does not need to compromise Oracle's infrastructure. They need access to a legitimate account that uses Oracle Email Delivery, whether through account compromise, a purchased account, or a trial tenant. Once they have that access, every email they send inherits the authentication posture of the legitimate domain.

The attached PDF (Quote_QT-14778_1780331963059.pdf, 18,471 bytes, MD5: 014daec2043b7f89b6bb7d4911b377c9) scanned clean. No embedded JavaScript. No AcroForm submit actions. No OpenAction or Launch payloads. No mailto-based credential-harvesting links. The file appeared to be a legitimately generated PDF from a report-generation library (bfo.com producer metadata). It contained branding links to hillas[.]com.

A clean attachment scan does not make the email safe. Static-clean PDFs are a known element of multi-stage invoice fraud. The initial email establishes the vendor relationship. A follow-up, often from a slightly different address or with "updated" payment details, delivers the actual fraudulent wire instructions. The first PDF's cleanliness is the trust anchor for the second email's payload.

The Return-Path revealed additional detail: bounces+[recipient-username]=[recipient-domain][@]iad1.rp.oracleemaildelivery.com. This is Oracle's Variable Envelope Return Path (VERP) format, used for bounce tracking. Its presence confirms the message was sent through Oracle's delivery pipeline rather than being spoofed to appear that way.

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

This attack maps to MITRE ATT&CK T1566.001 (Phishing: Spearphishing Attachment) for the PDF-based delivery vector, and T1585.001 (Establish Accounts) for the use of a legitimate platform account to send the message.

Behavioral Detection Beyond Authentication

When SPF, DKIM, and DMARC all pass, traditional gateway filters lose their strongest negative signal. The attachment scanned clean. The links in the body pointed to real Adobe pages. Every technical indicator said this email was legitimate.

Themis, our Adaptive AI, evaluated the message against behavioral patterns rather than technical signatures. An attachment-first email with no contextual detail, from a first-time sender, using a third-party delivery service, matches an invoice-phishing profile that has been validated across thousands of reported incidents. The absence of a signature block, the legacy HTTP Adobe URL, and the mismatch between the From address and the Reply-To domain all contributed to the risk assessment.

Community intelligence flagged similar Oracle Email Delivery patterns across multiple tenants during this period. Cross-organization reporting confirmed that the combination of NetSuite-formatted Reply-To addresses with attachment-first bodies was appearing in coordinated campaigns.

Research shows that 67.5 phishing emails per 100 mailboxes per month bypass traditional secure email gateways. Authenticated delivery through enterprise SaaS platforms accounts for a growing share of those bypasses because the infrastructure itself is indistinguishable from legitimate business email.

Defending Against Authenticated Invoice Lures

Accounts payable teams are the primary targets for this attack pattern. Defensive recommendations include:

• Verify before opening. Any invoice or quote from an unknown sender should be verified through a known contact method before the attachment is opened, especially when the email body contains no contextual detail.
• Flag attachment-first patterns. Mail rules can flag messages where the body length is below a threshold but an attachment is present, particularly from first-time senders.
• Treat Reply-To mismatches as signals. When the From domain and Reply-To domain differ, the email warrants additional scrutiny regardless of authentication results.

IOC Table