A Fake Malwarebytes Renewal, Signed by Google

The message that reached a senior executive at a hospitality company one Wednesday afternoon carried the one logo most people have been trained not to second-guess: Google Calendar. An invitation, an RSVP row with Yes / No / Maybe buttons, a "When" field, an organizer. The kind of thing that shows up a dozen times a day and gets a reflexive glance.

Inside the invite was an invoice. "Malwarebytes Security Operations," it read. Renewal Reference #: MP5U8EZVDV1B1J. Premium Family Plan, four-year term, unlimited devices. Amount paid: $598.75 USD. Payment method: automatic renewal, credit card. Billing cycle: four years, non-cancelable. And then, in bold, the part that does the work: "To dispute any unauthorized charges, please call our Fraud Prevention line at +1 (810) 228-4980." A second number, a "Support Hotline," sat higher up in the body.

No link to a login page. No attachment to open. No credential form. The entire payload was two phone numbers and a story about money already gone.

A Renewal Notice Aimed at the Corner Office

The target was not a random mailbox. It was a senior leader, the kind of recipient security teams flag as high-value because a successful pretext against them carries more authority and more budget than one against a help-desk queue. The lure was built to fit that reader. A four-year, non-cancelable charge on a personal-sounding "Family Plan" is exactly the sort of thing a busy executive might not recognize, might assume a family member set up, and might want cleared quickly and quietly. The "non-cancelable" language and the fraud-line framing are designed to convert confusion into a phone call.

That framing is the whole attack. Callback phishing, also known as telephone-oriented attack delivery (TOAD), skips the malicious webpage entirely. The email exists only to get someone to dial. On the other end is a live operator or a convincing script, ready to walk the caller through "reversing" the charge, which in practice means collecting card details, account credentials, or remote-access approval under the banner of customer support.

Nothing to Scan, Everything Signed

The security stack had almost no technical artifact to grab onto. Every action button in the invite pointed to calendar.google.com and scanned clean, because that is genuinely where they pointed. The attached invite.ics was a plain iCalendar file produced by Google, containing only mailto: addresses, no embedded HTML, no alarm actions reaching out to external hosts, no script. The attachment sandbox returned a clean verdict. URL reputation had nothing to weigh.

Authentication looked healthy at a glance. DKIM passed twice, once with header.d=google.com and once with a signature tied to a gappssmtp.com selector, the tell of a real Google Workspace account provisioned on the attacker's own domain. Composite authentication passed. Microsoft's own spam confidence level came back at -1, the value reserved for mail it trusts enough to skip filtering. The visible "Sender" was calendar-notification@google.com.

Peel back one layer and the picture changes. The organizer address was anestiwlton@betskl[.]com, a domain with no relationship to Malwarebytes and a gibberish display name that did not match the brand it claimed to represent. SPF returned none. DMARC returned none. And the domain itself, betskl[.]com, was registered through Registrar.eu at 16:45 UTC on June 17, 2026, then used to send this invite roughly three hours later at 19:53 UTC the same afternoon. Privacy-shielded, DNSSEC unsigned, a one-year registration. No history, no reputation.

None of that reached the URL scanner, because there were no attacker URLs to scan. DKIM's passing signature confirmed that Google sent the message. It said nothing about whether the sender, or the brand in the body, was real.

The Brand Did the Convincing

There was no domain spoofing here, and that distinction matters. The attacker never tried to forge a Malwarebytes address or trip an anti-spoofing rule. The impersonation lived entirely in the content: the vendor name, the invoice layout, the reference number, the security token, the confident "we appreciate your trust in Malwarebytes" sign-off. Structurally, the message is honest about being from a random domain. It just counts on the reader looking at the brand, not the envelope.

That choice is why authentication controls have nothing to say about it, and it borrows credibility from a company that actively warns against this exact move. Malwarebytes' own guidance is blunt: legitimate vendors do not cold-call you about charges, and support runs through the Help Center and account portal, not an ad-hoc 810 number in a calendar invite (Malwarebytes: tech support scams). Microsoft's Digital Defense Report has tracked the same shift, noting the growing misuse of legitimate services and impersonation of trusted brands to deliver fraud (Microsoft Digital Defense Report 2024).

The Executive Made the Call, to Report It

The turning point was not an automatic block. It was the target. The executive did not call either number. She flagged the message with a simple note, "Don't know this sender," and reported it, exactly the instinct security-awareness programs are built to create in senior staff.

That report did not stand alone. Themis had already scored the message as suspicious, labeling it a vishing attack against a VIP recipient and pointing at the freshly registered return-path domain and the language patterns in the invite. The confidence score sat at 52 percent, in the band where the platform surfaces a message for human review rather than treating it as obviously benign or obviously malicious. Human judgment and platform signal pointed the same direction. The incident was approved for action, the message quarantined, and the copy permanently deleted from the mailbox.

The FBI's Internet Crime Complaint Center has tracked callback and tech-support fraud as a persistent, heavily underreported category, one that leans on urgency and impersonation rather than malware (FBI IC3 2024 Internet Crime Report). Verizon's most recent Data Breach Investigations Report continues to place social engineering and the human element among the leading paths into an organization (Verizon DBIR). This case is a clean illustration of both: no exploit, no dropper, just a plausible story and a number to call.

See Your Risk: Find out how many threats like this your current security stack is missing

Indicators of Compromise

What Behavioral Detection Actually Means Here

Map the attack to MITRE ATT&CK and it is deliberately thin: Impersonation (T1656) for the borrowed Malwarebytes identity, Phishing for Information (T1598) for the off-channel voice harvest, Spearphishing Attachment (T1566.001) for the calendar-invite delivery, and User Execution (T1204) for the one action the whole thing depends on, picking up the phone.

Every technical control that email security is usually praised for was satisfied here. DKIM passed. The attachment was clean. The links were legitimate. The message reached the inbox with a trusted spam score. Stopping this class of attack means grading the things those controls ignore: the age and hygiene of the sending domain, the mismatch between a claimed brand and its envelope, financial urgency inside a calendar invite from an unknown external organizer, and callback numbers that fit known vishing patterns. It also means keeping the human sensor sharp. Security awareness training that specifically covers callback fraud and calendar-based delivery is what turned a VIP target into the first line of detection instead of the victim.

The uncomfortable part is that this attack did not beat a misconfigured filter. It went around a well-tuned one, on purpose. When the payload is a phone number wrapped in a real brand and signed by Google, the signal is not in the link. It is in the registration date, the missing SPF record, and the executive who decided the invite was worth reporting instead of answering.