The Collections Notice From a Fortune 500 Lab: Compromised Thermo Fisher Account via Oracle Cloud Relay

Written by Audian Paxson | May 28, 2026 11:00:00 AM

TL;DR A phishing email arrived from andrew.musial@thermofisher[.]com, a real address at Thermo Fisher Scientific, one of the largest life sciences companies in the world. The message was sent through Oracle Cloud email infrastructure at smtp2[.]email[.]us-ashburn-1[.]ocs[.]oraclecloud[.]com (IP 147[.]154[.]59[.]193) and passed SPF, DKIM, and DMARC. The subject line referenced a collections notification for a generic account number. The body instructed the recipient to review an attached document, but contained no inline payment details, no personalization, and multiple quality issues including redundant phrasing and punctuation errors. All links in the message pointed to legitimate Microsoft support destinations. The attachment was the sole payload vector. Themis flagged the message on behavioral signals including first-time external sender, attachment-focused CTA with no contextual detail, and language quality anomalies.

Severity: High Credential Harvesting Account Takeover MITRE: {'id': 'T1566.001', 'name': 'Phishing: Spearphishing Attachment'} MITRE: {'id': 'T1078', 'name': 'Valid Accounts'} MITRE: {'id': 'T1036.005', 'name': 'Masquerading: Match Legitimate Name or Location'}

The email came from andrew.musial@thermofisher[.]com. Thermo Fisher Scientific: $45 billion in annual revenue, Fortune 500, one of the most recognized names in life sciences. SPF passed. DKIM passed. DMARC passed. The sending infrastructure was Oracle Cloud, a relay that Thermo Fisher legitimately uses for application-generated email. Every reputation signal pointed to a trusted corporate sender.

The message was a collections notice for "Account 100400." The body asked the recipient to review an attached document. That was the entire payload delivery mechanism.

Authenticated Infrastructure From a Trusted Enterprise

The email was relayed through smtp2[.]email[.]us-ashburn-1[.]ocs[.]oraclecloud[.]com at IP 147[.]154[.]59[.]193, Oracle Cloud Infrastructure's email delivery service in the Ashburn, Virginia region. The domain thermofisher[.]com has been registered since 2006, managed by MarkMonitor, the registrar used by most Fortune 500 companies for domain protection. SPF authorized Oracle Cloud's sending IPs. DKIM alignment confirmed the message was signed with Thermo Fisher's keys. DMARC passed.

This is the account takeover problem in its purest form. The attacker did not build infrastructure, register a domain, or configure DNS records. They compromised a legitimate account and inherited decades of domain reputation, enterprise-grade authentication, and the implicit trust that security tools extend to known corporate senders. A secure email gateway evaluating sender reputation would score this message favorably before ever examining the content.

The Quality Signals That Did Not Match the Sender

The only links in the message pointed to Microsoft support destinations (aka[.]ms URLs), all of which scanned clean. The attachment was the sole vector, and the email body provided no inline invoice details, no payment amounts, no specific dates, and no recipient personalization beyond the generic account number "100400."

The language quality did not match what you would expect from a Fortune 500 finance department. The body contained redundant phrasing, inconsistent punctuation, and spacing errors. These are not decisive individually, but they are the kind of friction that indicates the message was composed by someone other than the account owner. Legitimate collections notices from enterprise ERP systems follow rigid templates with consistent formatting.

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

What Behavioral Detection Evaluates When Reputation Is Clean

The email passed every static check. The domain is real. The authentication is valid. The links are clean. The detection surface is entirely behavioral: a first-time external sender with no prior communication history, an attachment-focused CTA with zero contextual detail, and language quality inconsistent with the claimed sender's organizational standards. These are the signals that Adaptive AI weighs when authentication and content scanning find nothing to flag. Themis identified the anomaly pattern and the message was quarantined.

Indicators of Compromise

Type	Indicator	Context
Sender Address	`andrew.musial@thermofisher[.]com`	Compromised Fortune 500 corporate account
Sending Domain	`thermofisher[.]com`	Registered since 2006, managed by MarkMonitor
Sending Relay	`smtp2[.]email[.]us-ashburn-1[.]ocs[.]oraclecloud[.]com`	Oracle Cloud Infrastructure email service
Sending IP	`147[.]154[.]59[.]193`	Oracle Cloud relay, Ashburn VA region
Auth Results	SPF: pass, DKIM: pass, DMARC: pass	Full authentication via corporate infrastructure
Subject Line	`[External] Collections Notification for Account 100400`	Generic account number, no recipient personalization
Links	`aka[.]ms` destinations only	All links to legitimate Microsoft support pages
Payload	Attachment (multipart/mixed)	Attachment-only CTA, no inline payment details
Content Anomalies	Redundant phrasing, punctuation/spacing errors	Quality inconsistent with Fortune 500 templates

MITRE ATT&CK Mapping

Technique	ID	Relevance
Phishing: Spearphishing Attachment	T1566.001	Attachment as sole payload delivery vector
Valid Accounts	T1078	Compromised Thermo Fisher corporate account used for sending
Masquerading: Match Legitimate Name or Location	T1036.005	Real Fortune 500 identity and Oracle Cloud infrastructure

Email Attack of the Day is a daily series from IRONSCALES spotlighting real phishing attacks caught by Adaptive AI and our community of 30,000+ security professionals. Each post breaks down one attack — what it looked like, why it worked, and what you can do about it.

View full post