A Fake Bitdefender Charge Showed Up on the Calendar, Not the Inbox

Most phishing attacks need you to click something. This one just needed you to check your calendar.

A government employee received what appeared to be a legitimate Google Calendar invitation. The subject referenced a payment confirmation and a membership ID. Inside the calendar event, a fake Bitdefender subscription renewal for $483.22 was waiting, complete with transaction details, a customer ID, and an "emergency" phone number for cancellations. No malicious links. No weaponized attachments. Just a .ics file that forced the recipient's calendar client to render an RSVP prompt (Yes, No, Maybe) alongside the fraudulent charge notice.

The sending domain, yukimi[.]org, was registered exactly one day before this email was sent. It published no SPF, DKIM, or DMARC records. And yet the message arrived through a legitimate government mail relay, passed through Mimecast scanning, and landed in the inbox with interactive RSVP buttons pointing to calendar[.]google[.]com. Every URL a scanner could inspect was clean.

When the Attack Surface Is the Calendar Client Itself

The .ics attachment used METHOD:REQUEST with RSVP=TRUE and PARTSTAT=NEEDS-ACTION. In practical terms, this combination tells the recipient's email and calendar client to treat the message as an actionable event that requires a response. The user doesn't need to open an attachment or click a suspicious link. Their calendar app does the work automatically, rendering the event details and presenting response buttons.

This is a deliberate evasion strategy. Link-based detection, URL sandboxing, and attachment scanning all look for something to analyze. When the payload is social engineering text embedded in a calendar event description, and every interactive element routes to Google's own infrastructure, there's nothing for traditional tools to flag.

The attack maps to MITRE ATT&CK T1566.001 (Phishing: Spearphishing Attachment) for the .ics delivery mechanism, T1036.005 (Masquerading: Match Legitimate Name or Location) for the Bitdefender brand impersonation, and T1204.002 (User Execution: Malicious File) for the calendar client auto-rendering behavior.

Infrastructure Built to Disappear

The attacker infrastructure tells a clear story of disposability. The domain yukimi[.]org was registered with Cloudflare on March 4, 2026, and the attack email was sent on March 5. One day. The WHOIS data shows privacy-protected registration with no organizational details, DNSSEC unsigned, and the domain set to expire March 4, 2027 (the minimum one-year registration). It was built to be used once and forgotten.

The organizer email, sudhakarjoshilkar@yukimi[.]org, was configured through Google Workspace (the DKIM signature references yukimi-org[.]20230601[.]gappssmtp[.]com). This gave the attacker access to Google Calendar's native invitation system, meaning the .ics file was generated by Google's own servers. The From header displayed "Google Calendar" with the address calendar-notification@google[.]com, a legitimate Google system address that added another layer of credibility.

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

The delivery chain exploited a government mail relay at shelbycountytn[.]gov (IP: 4[.]7[.]129[.]194). The message traversed Google SMTP, then Mimecast relay scanning, then the government's on-premises Postfix server, and finally Microsoft Exchange before landing in the recipient's M365 mailbox. At the Mimecast relay, DKIM passed for both google.com and the attacker's gappssmtp subdomain. But at the final Microsoft destination, SPF returned none (yukimi[.]org has no SPF record) and DMARC failed. The recipient's own gateway even injected a warning banner: "This EMAIL was not sent from a Shelby County Government email address. Please use caution."

That banner was the only visible red flag. And for a calendar invite impersonating a software vendor, not the government itself, most users would consider it irrelevant.

The Social Engineering: Panic Without a Link

The event description impersonated "Team Bitdefender 360 Deluxe" and claimed the recipient's account had been billed $483.22 for a product called "AuraShield Pro" with a four-year membership. Neither "Bitdefender 360 Deluxe" nor "AuraShield Pro" are real Bitdefender product names. The description included fabricated transaction details (Client UID, Customer ID, payment mode) designed to look legitimate at a glance.

The entire attack hinged on one CTA: a phone number formatted as 1{808} 216-4914 (the curly braces likely intended to evade phone number detection). This is classic callback phishing, where the goal is to get the victim on a phone call with a fake support agent. Once connected, those operators typically walk victims through "cancellation" processes that involve remote access tools, gift card payments, or wire transfers. The FBI IC3 2024 report documented callback phishing as one of the fastest-growing social engineering vectors, precisely because there are no links to scan.

Indicators of Compromise

IRONSCALES Themis analysis flagged this message through sender domain age correlation, authentication failure aggregation (SPF=none, DMARC=fail), and behavioral signals including the mismatch between the organizer domain and the impersonated brand. The absence of traditional phishing indicators (malicious URLs, weaponized attachments) made this a case where AI behavioral analysis outperformed signature-based detection.

What This Means for Your Calendar Security Posture

Calendar invite phishing exploits a gap that most SEG configurations ignore entirely. Here's what to prioritize:

1. Treat .ics files as content, not metadata. Calendar attachments with METHOD:REQUEST should be inspected for social engineering signals in the DESCRIPTION field, not just scanned for embedded URLs.

1. Enforce domain age thresholds. Any email originating from a domain registered within the past 30 days should receive elevated scrutiny, regardless of whether it passes basic authentication checks.

1. Monitor for callback phishing indicators. Phone numbers in email bodies (especially with unusual formatting like curly braces or parenthetical obfuscation) combined with urgency-driven billing claims are strong callback phishing signals.

1. Don't rely on URL scanning alone. This attack contained zero malicious URLs. Every link pointed to calendar[.]google[.]com. If your detection strategy requires a bad link to trigger, attacks like this will sail through.

1. Train users on calendar-based threats. Most security awareness programs cover link clicking and attachment opening. Few address the scenario where a calendar event itself is the attack surface.

The shift from link-based phishing to interaction-based phishing (calendar RSVPs, QR codes, callback numbers) is accelerating. The attacks that don't need you to click a link are often the ones that need you to pick up the phone.