The content disarm and reconstruct gateway did exactly what it was designed to do. The XLSX arrived flagged malicious. Before delivery, Votiro CDR quarantined the file, generated a clean replacement report, and re-queued the message for the inbox.
What arrived was a PDF notification titled "attachment_blocked.pdf," a "View Document" button linking to a SmartLink on t-sml[.]mtrbio[.]com, and a calendar invite from calnder@vantage[.]bank. The sender was "Finance Team | Payment Notifier." The subject was marked urgent.
The file was gone. The attack was not.
This spearphish was built with three coordinated payloads targeting an analyst at a regional financial institution. The email impersonated OfficeTools Document Services, a document management platform used in financial workflows, and cited a pending "Vantage_07918 – Disbursement Approval" requiring electronic signature.
The personalized XLSX was named Vantage_Document_[recipient][.]xlsx. It contained no macros, no embedded URLs. It contained a single instruction: "Scan the QR code or visit the link provided in your email to access the full document." The file was a social engineering redirect, not the payload. The payload was the SmartLink in the email body. Votiro CDR flagged the XLSX based on upstream signatures and replaced it with a blocking notice.
The SafeLinks-wrapped link pointing to hxxps://t-sml[.]mtrbio[.]com/public/smartlink/onedrive-msexchange-workers-dev-email-160 was scanned at time of delivery. It returned clean. It was passed.
The .ics calendar invite was scanned. It returned clean. It was passed.
When the quarantine notification arrived in the same inbox alongside the "View Document" button, the signal the recipient received was: something was blocked, but there is still a document to review.
CDR tools are scoped to file content. They strip active content from attachments, quarantine executables, and flag known-bad signatures. A SafeLinks URL in an email body is a different problem evaluated by a different scanner against a different signature set.
The attacker appears to have understood this. The XLSX itself did not contain the credential harvesting mechanism. It contained instructions to use the link. Blocking the XLSX removed one path to the link while leaving the link intact. If the recipient clicked "View Document" directly from the email body, the XLSX had already done its job or was never needed.
See Your Risk: Calculate how many threats your current email security is missing
This is the architecture of a multi-vector spearphish: credential theft delivered through a file, a link, and a calendar invite simultaneously, with the expectation that at least one path survives whatever control is in place. According to the Verizon 2024 Data Breach Investigations Report, phishing remains the dominant entry point in financially motivated breaches. The volume is not the issue. The architecture is.
The automation artifacts here are worth examining closely.
The email subject read "[IMPORTANT] Update Required: Q4 Salary Review." The email body described a disbursement approval requiring electronic signature. A salary review notification and a disbursement approval workflow are different enough that a human-authored spearphish would not mix them. These two templates came from different kit components assembled without a consistency check.
The calendar invite organizer was set to calnder@vantage[.]bank. The intended value was probably calendar@vantage[.]bank or a similar service alias. A single-character typo in the organizer field of an automated .ics file is the fingerprint of a phishing kit generating calendar invites from a victim list with a script error in the organizer template (T1566.001).
The .ics filename itself contained the recipient's email address encoded in ASCII hex. That string made it into the delivered filename, visible to anyone who looked. It was likely included for campaign tracking or victim deduplication on the attacker's side. The XLSX was generated by Python's openpyxl library, with a creation timestamp approximately five and a half hours before delivery. This is a batch generation pipeline, not a hand-crafted message.
The Reply-To header pointed to noreply@vantage[.]bank. The List-Unsubscribe header pointed to noreply@vantage[.]bank. Both are designed to make any automated responses appear bank-originated (T1036.005). The actual SMTP envelope was emailxoj@netvigator[.]com, a Hong Kong ISP.
IRONSCALES flagged this at 90% confidence, tagging it "Credential Theft" and "VIP Recipient" (T1566.002).
Several compound signals produced that score. The sending address and the claimed organization had no prior relationship with this mailbox. The email arrived with X-Priority: 1 and Importance: High set by the sender. An external first-time contact marking their own message urgent is a behavioral anomaly.
The SmartLink pointed to a domain unrelated to OfficeTools, the platform the email claimed to represent. The path structure (/public/smartlink/onedrive-msexchange-workers-dev-email-160) mimicked OneDrive URL patterns (T1027), another mismatch for a purported OfficeTools document workflow.
Post-CDR transit also broke SPF, DKIM, and DMARC for netvigator.com, because Votiro's relay IP was not in netvigator.com's SPF record and body modification invalidated the DKIM signature. This is expected behavior when mail transits a CDR gateway. It is also a compounding signal when evaluated alongside everything else.
The XLSX malicious verdict, the first-time sender flag, the VIP target designation, and the link-domain mismatch together produce a confidence score that no single indicator generates alone.
CDR is a useful control. It worked here. Votiro blocked a malicious XLSX before it reached the inbox. The problem is that the control was scoped to files, and this attack included more than files.
According to IBM's 2024 Cost of a Data Breach report, the average cost of a phishing-initiated breach reaches $4.88 million. For teams using CDR as a primary email defense layer, this case illustrates the gap between what CDR solves and what attackers design around it.
Advanced malware and URL protection requires link evaluation at time of click, not only at delivery. A SmartLink that returns clean at 2:39 PM may route to a credential harvesting page by 3:00 PM. Static scans at delivery capture reputation at that moment, not what the URL resolves to when the recipient clicks.
For M365 environments running CDR alongside Exchange Online Protection and SafeLinks, the question to ask after an incident like this is not whether the file was blocked. It is whether the link in the same email was evaluated with the same rigor, at the time it mattered. CISA's guidance on recognizing and reporting phishing emphasizes sender verification and link inspection as the primary defenses against credential-harvesting attempts. The IRONSCALES platform evaluates behavioral signals in combination, which is why this one was caught despite every individual component passing its point-in-time scan.
Three vectors. One blocked. Two delivered. The attack continued anyway.
| Type | Indicator | Context |
|---|---|---|
| IP | 44[.]206[.]222[.]91 | Votiro CDR relay (AWS EC2, us-east-1) |
| IP | 151[.]241[.]154[.]219 | Apparent attacker origin (Hong Kong) |
| Domain | netvigator[.]com | Sending domain (Hong Kong ISP) |
| Domain | t-sml[.]mtrbio[.]com | SafeLinks-wrapped SmartLink redirect target |
emailxoj@netvigator[.]com | Envelope sender | |
calnder@vantage[.]bank | Typosquatted calendar organizer (kit error) | |
| File (MD5) | c08b0fe953903801a319ca82c2548d83 | Malicious XLSX |
| File (SHA-256) | 87b73d04ae08633fa1846bad74ea0a84c87b6bf837dcc1707cea98c39bde9b47 | Malicious XLSX |