Threat Intelligence

The Government Card Alert That Lost Its Authentication in Transit

Written by Audian Paxson | Jun 19, 2026 11:00:00 AM
TL;DR A card replacement notification arrived claiming to be from Direct Express, the US government's prepaid debit card program for federal benefit recipients. The message was sent via SendGrid through a Conduent payment processing subdomain and relayed through a Cisco IronPort gateway. Authentication results diverged at each hop: SPF and DKIM passed at the IronPort gateway, but SPF failed, DKIM failed (body hash mismatch), and DMARC failed at the recipient tenant. The IronPort Outbreak filter classified it as Phish. Despite this, the message received SCL=-1 (trusted) because the IronPort relay IP was on the recipient's allow-list. The email contained no links or attachments, only a phone number and a reference to the legitimate Direct Express website, consistent with a vishing setup. A SendGrid tracking pixel provided mailbox activity confirmation.
Severity: Medium Government Impersonation Vishing MITRE: {'id': 'T1566.003', 'name': 'Phishing: Spearphishing via Service'} MITRE: {'id': 'T1598.001', 'name': 'Phishing for Information: Spearphishing Service'} MITRE: {'id': 'T1036.005', 'name': 'Masquerading: Match Legitimate Name or Location'}

The upstream gateway said it was phishing. The allow-list said it was trusted. The authentication said it was broken. The message landed in the inbox.

A card replacement notification arrived at a healthcare system employee's mailbox from no-reply@notifications[.]usdirectexpress[.]com, the notification address for the US government's Direct Express prepaid debit card program. The email informed the recipient that a card replacement had been requested on their account and directed them to call 1-888-741-1115 or visit www[.]usdirectexpress[.]com to lock their card.

Authentication That Degraded at Every Hop

The message originated from SendGrid infrastructure at 149[.]72[.]68[.]216 (the o1[.]ptr8157[.]conduent[.]com relay), where it authenticated correctly: SPF passed for em231[.]conduent[.]com and DKIM was verified for conduent[.]com. But the message then passed through a Cisco IronPort email security gateway at esa2[.]hc3244-53[.]iphmx[.]com (139[.]138[.]59[.]32) before reaching the recipient's Microsoft tenant.

At the recipient, every authentication check failed. SPF failed because the IronPort gateway IP was not in the em231[.]conduent[.]com SPF record. DKIM failed with a body hash mismatch, indicating the gateway modified the message content during scanning. DMARC failed because the header From domain (notifications[.]usdirectexpress[.]com) did not align with either the SPF domain (em231[.]conduent[.]com) or the DKIM signing domain (conduent[.]com).

Contradictory Security Verdicts

The IronPort gateway's own Outbreak filter classified the message as "Phish." But the IronPort relay IP was on the recipient organization's allow-list (IPV:CAL in the antispam headers), so Microsoft assigned SCL=-1, the highest trust score. The message bypassed spam filtering entirely and landed in the inbox despite three authentication failures and a phishing classification from the relay itself.

The email contained no links in the body and no attachments. The only interactive elements were a phone number and a URL in plain text, consistent with a vishing setup where the attacker directs the victim to call a spoofed support line. A SendGrid tracking pixel confirmed the mailbox was active. Themis evaluated the sender authentication breakdown and flagged the message for review at 52% confidence.

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

Indicators of Compromise

TypeIndicatorContext
From Domainnotifications[.]usdirectexpress[.]comGovernment benefit card notification domain
Return-Pathbounces+[id]-[encoded-recipient]@em231[.]conduent[.]comVERP-encoded bounce, SendGrid
SendGrid Relay149[.]72[.]68[.]216 (o1[.]ptr8157[.]conduent[.]com)Upstream SPF pass
IronPort Gateway139[.]138[.]59[.]32 (esa2[.]hc3244-53[.]iphmx[.]com)Phish classification, allow-listed
DKIM Signatured=conduent[.]com, selector psgBody hash failed at recipient
Auth at RecipientSPF: fail, DKIM: fail, DMARC: failcompauth=none reason=405
SCL-1Trusted via allow-list override
IronPort-OutbreakPhish - PhishGateway's own classification
Tracking Pixelu12898415[.]ct[.]sendgrid[.]net/wf/openSendGrid open tracking

MITRE ATT&CK Mapping

TechniqueIDRelevance
Phishing: Spearphishing via ServiceT1566.003SendGrid/Conduent infrastructure for delivery
Phishing for Information: Spearphishing ServiceT1598.001Card replacement alert designed to trigger phone call
Masquerading: Match Legitimate Name or LocationT1036.005Direct Express government program impersonation
Email Attack of the Day is a daily series from IRONSCALES spotlighting real phishing attacks caught by Adaptive AI and our community of 35,000+ security professionals. Each post breaks down a real attack. What it looked like, why it worked, and what to do about it.

Related attacks

Attack What happened
The Azure Alert That Billed You $459: When Microsoft's Own Infrastructure Delivers the PhishA phishing campaign used Azure's own notification system to send fraudulent billing alerts from Microsoft's authenticated infrastructure.
The Zelle Confirmation That Couldn't Spell Its Own Name: Template Artifacts, Placeholder Leaks, and a TOAD CallbackA Zelle payment confirmation from a Gmail address passed SendGrid authentication but failed DMARC for gmail.com.
Someone Filed a False Positive on This Azure TOAD Scam. Here's Why That's the Whole Point.An attacker built a real Azure subscription, created a resource group and metric alert rule.
The Voicemail That Wasn't: How Calendar File Attacks Bypass Email SecurityAn attacker sent an empty email with a voicemail-themed .ics calendar attachment from a Japanese domain while impersonating a US financial services...
The Payload Was a Phone Number: How a Google Calendar Invite Weaponized VishingA Google Calendar invite with a fake $399.77 charge and a toll-free callback number.