Threat Summary
Fortra Intelligence and Research Experts (FIRE) have identified an ongoing campaign combining ConsentFix (also known as device code phishing) to harvest Microsoft account credentials and calendar phishing (or CalPhishing) to bypass security controls and push users closer to the 'trusted' workflow. This activity is likely linked to the EvilTokens AI-enabled phishing kit, which has been known to include calendar phishing as an option. However, CalPhishing appears to be the increasingly preferable method of delivery thanks to its ability to bypass defences.
CalPhishing is challenging to block, as the email and attached iCalendar (.ics) file does not trigger email security tools. CalPhishing is then designed to push the user to trust the workflow, rather than question the source, circumventing much of the phishing awareness training that is focused on source validation.
ConsentFix is effective because the workflow presents a trusted login popup with a legitimate MS authentication page and then steals the session leading to account takeover.
Calendar phishing and ConsentFix are complimentary techniques that improve the chances of successful delivery and credential harvesting and are challenging for organizations to mitigate without additional configurations that are highlighted at the end of this article.
CalPhishing Introduction
The FIRE-identified attack campaign delivers domain renewal lures through calendar invites that are immune to standard remediation actions. Decoupled from their original delivery, the artifact remains in the victim’s calendar unless Hard-Delete is enacted, leaving the meeting and its reminders still visible and functioning as a legitimate meeting would.
A meeting request is used as the primary interaction point for the campaign, surfacing the lure directly in a trusted workflow, rather than relying on user engagement within the email body. Many of these calendar requests are framed as administrative alerts, intentionally designed to abuse user trust, lack of scrutiny, and trained behavior to act quickly on potential service impacts. A soft delete or move to junk does not remove the meeting entry from the calendar itself, leaving the victim vulnerable to malicious content.
We have identified two distinct phishing lures in this campaign, one focused on a domain renewal or expiry invite impersonating Microsoft 365 administrative alerts and a second that requires a digital signature for an invoice or vendor renewal.
Let’s first see what this phishing type looks like and deconstruct/observe the mechanisms used.
CalPhishing Steps
Initial Delivery
The email presents as a high priority notification. The email does not have attachments and minimal content overall, as the focus is the invite. This is a simple but effective evasion tactic, appearing harmless and expected to email filters and gateways.
Here are the details.
Subject Examples:
[Urgent]: <domain>* Domain Renewal Failed <DATE & TIME>
[🚨]: Renewal Failed for [ <domain>] - <DATE & TIME> - ID:#(<ID>)
[ALERT]: Failed Renewal for [ <domain> ] - <DATE & TIME> - ID:#(<ID>)
Reminder for Signature - Vendor Information Verification
The ‘Renewal Failed’ subject creates a strong sense of urgency, an expired domain can mean an unreachable website - but does depend on successfully identifying and targeting a web admin, or another specific role who would be involved in domain registrations.
We have not observed any evidence of sophisticated targeting of web admins so believe this is a spray and pray tactic hoping to harvest privileged credentials.
The ‘Reminder for Signature’ subject is broader. Presenting a generic call to digital sign a document.
The sender appears aligned to Microsoft 365, however the underlying infrastructure originates externally and does not match legitimate Microsoft sources.
Authentication signals pass at a superficial level, reducing the likelihood of immediate rejection and allowing delivery into user inboxes. The sending pattern suggests use of external infrastructure, potentially through a compromised / abused third-party domain or legitimate company.
The email contains a calendar invite attachment (.ics) which is processed by the Outlook client, resulting in a meeting being created in the user’s calendar, independent of the user seeing or interacting with the email.
User Interaction Flow
Once delivered, the behavior shifts away from email.
The invite surfaces as a meeting in the user’s calendar. It appears legitimate, carries urgency, and presents the usual options but being Tentative by default.
The meeting includes an attached HTML file masquerading as an admin portal resource. The location and description reinforce service impact and push the user towards action. The HTML set in the .ics is rendered in the body of the meeting with the set URL as the click option.
There are no obvious indicators of malicious intent at the calendar level.
The design relies on the user trusting the workflow rather than questioning the source.
Payload Delivery
The attached HTML file leads to a credential harvesting flow.
The HTML attachment is rendered in the meeting invite itself, after the .ics gets processed. What this means is that the attachment can be used as a required action before the meeting, leading the user to open it.
The intention is that the user presses the view document button.
Opening the attachment presents a page requiring user interaction, the first prompt is for a fake Cloudflare verification page. This is to stop Bot Scanning, track clicks to recipient sources and evade detection by layering the delivery.
After ‘verification’, the user is taken to a fake Docusign page that requires authentication with a Microsoft account. Following the directed workflow, the user is presented with a legitimate Microsoft Device Authentication pop-up.
On successful validation, the token is stolen and page redirects to a random legitimate vendor (google.com, amazon.com). This is typical of ConsentFix attacks.
At this point, the account has been compromised. We will discuss the full impact in the next section.
For the ‘Domain Renewal’ lure. The workflow is the same, but the user is presented with a page mimicking a domain registrar, in this case GoDaddy.
The branding is clean and minimal, with no obvious indicators to raise suspicion, and the user is prompted for the password, as the username is pre-populated with the target’s email address. This is an indicator of tailoring to the recipients in a high volume, possibly by using AI tooling or automated scripts to create unique tracking URLs tied to the target user.
The session allows a limited number of interactions attempts before redirecting to a legitimate site. This is interesting and introduces a further level of evasion, as it reduces suspicion during repeated testing and makes sandboxing or repeated analysis less reliable.
Impact
We have looked over a few key components but one part we can cover is impact. In other words, what can happen once the end user receives the invite.
Here are the types and behaviors:
User receives an email with a meeting invite attached.
The Outlook Client scans and recognizes the .ics, takes the commands from the attachment and displays the invite accordingly.
User sees the meeting as tentative in the calendar and gets prompted / reminded.
Actions can range from an attachment-based focus, to URL click prompts via the HTML page rendered in the body or actual meeting invites- the initial contact before the phishing action.
Depending on the type, the way the body of the invite varies but one thing is for sure, this has the same targets as a phishing email: credentials or authentication token, initial point of malware delivery and/or access to high privileged accounts.
Once the recipient takes the action, let’s say an IT admin does input the credentials to the phishing page prompted via the meeting invite, the threat actor has the option of using the token to login into the systems freely, unless strict device restrictions are applied.
From there, threat actors have the option of shutting down infrastructure, implementing persistence or branching further to spear-phishing, if the permissions do not allow for the target to be met.
ICS Structure and Abuse
The .ics file itself is straightforward and highlights how little is required to execute this attack.
At its core, it is just structured text which the email client parses and renders into a calendar event table. There is no requirement for exploit code or attachment execution.
Key fields are abused to carry the phishing content:
SUMMARY is used to create urgency and drive initial attention
DESCRIPTION contains the bulk of the messaging, including service impact and instructions or HTML with targeted content
LOCATION is used to reference an “attached” resource, often perceived as part of the meeting context, depending on the invite type
ORGANIZER is spoofed to appear Microsoft-aligned, leveraging “on behalf of” style representation which is not as easily scrutinized as a traditional sender address
Because these fields are rendered directly by the calendar client, the content is presented as it is set in the .ics or .calendar file.
Example structure:
BEGIN:VEVENT
SUMMARY: Domain Renewal Failed - Immediate Attention Needed
DESCRIPTION: Admin alert with service impact and billing failure messaging
LOCATION: Attached Admin Center File
ORGANIZER: CN="Microsoft Renewal Failed":mailto:[email protected]
DTSTAMP:20260326T100000Z
DTSTART:20260326T090000Z
X-MICROSOFT-CDO-BUSYSTATUS: CONFIRMED
X-MICROSOFT-ADMIN-ALERT-TYPE: DomainExpiry
END:VEVENT
This is legitimate calendar functionality being used as intended, with the malicious element embedded in the content.
Why This Works
This technique is effective because it aligns with normal operational behavior.
Calendar events are generally trusted more than emails and most phishing training does not include education around calendar invites. Framing the invite as an administrative alert adds to the urgency, imagine opening up your calendar when you first logon to see what the day holds and seeing an urgent event. In enterprise environments, users can be conditioned to act quickly on anything suggesting service impact, and links embedded within calendar content are rarely scrutinized to the same level as email, which makes this Phish type more likely to be successful.
The interaction is also decoupled from the original delivery. Even if the email is questioned or removed, the event remains in the calendar, increasing the likelihood of interaction over time.
Post-Delivery Behavior
One of the more notable aspects is persistence.
The email can be removed or remediated, however the calendar event remains, unless the Hard-Delete option is used. This is a recent Microsoft post-report feature introduced to cover this phishing type.
In testing, standard remediation actions such as soft delete or move to junk did not remove the associated meeting entry.
The delivery is handled but the artefact remains if not carefully assessed and deleted, as the meeting is still visible to the user, reminders for the meeting start time will still apply and the malicious content will be visible/accessible.
Indicators of Compromise
Infrastructure
102naga26[.]com (multiple subdomains observed)
adprovider[.]tsu[.]ac[.]th
hxxps[:]//genthwuerdmarcus[.]com
hxxps[:]//secure[.]smartlytics.com[.]de
info@sinarsuburlogamindo[.]com
SHA’s would not be useful , the attachments are tailored to the recipient, indicating the usage of AI
Themes Observed
Microsoft 365 admin / billing failure
Domain renewal urgency
Service disruption warnings
Billing updates
Signature Required / Docusign
Detection Considerations
This type of activity can be missed, if detection is focused only on the email content.
Calendar artefacts are often not inspected to the same level. Events containing external URLs, .ics files with embedded links or attachments, and unusual meeting subjects tied to administrative actions can all indicate this type of delivery. Repeated event creation from non-trusted external senders is another signal.
Correlation becomes important here. Linking delivered emails, created calendar events, and subsequent web requests can help surface this activity more effectively.
Threat hunts through emails with .ics’s can be a helpful view into the internal threat trends. Seeing what targets your organization and how can be very useful, as it is likely that the one that will pass through will match an existing pattern or just showcase the target.
Example KQL
EmailAttachmentInfo
| where FileExtension contains ".ics"
| join kind=inner (
EmailEvents
) on NetworkMessageId
| where isnotempty(ConfidenceLevel)
//| where ThreatTypes1 != "Spam" - Might be useful to include, as spam threat types can include emails with no malicious intent, such as sales and marketing related emails.
Mitigation
There isn’t a single control that addresses this cleanly. The challenge here is that the activity spans both email and calendar, and most controls are still heavily email focused. Recently, Microsoft has addressed this issue, post bug report, by changing Hard-Delete Zapping option only to be able to remove the invite itself as well.
Some considerations:
Inspection needs to extend beyond the email body
The.ics content, embedded URLs, and attachments referenced within calendar fields should be treated the same way as traditional phishing indicators. External sender patterns tied to calendar delivery are also worth monitoring, especially where multiple events are being generated.
How calendar invites are handled becomes important. In environments where external collaboration is required, outright blocking is usually not practical. However, reducing implicit trust in how invites are processed can help, which includes reviewing automatic processing behavior and how events are surfaced to users.
Configuration-level options are worth exploring
Disabling or restricting automatic calendar processing via PowerShell has been discussed, although this is not always straightforward to apply consistently across user mailboxes and does not fully mitigate the issue, but it can definitely help.
Remediation workflows should also account for calendar artefacts
Removing the email alone is not sufficient if the event persists in the user’s calendar.
From a user perspective, this is still largely unaddressed. Calendar content is generally not treated as untrusted. Unexpected meetings, especially those tied to administrative or billing actions, should be approached with the same level of scrutiny as email. Links and attachments within events should be validated, and any service-impacting alerts should be confirmed through official portals.
In the previous outlook version, you were able to set the auto-accept to be turned off but that is unfortunately not visible for end users anymore. Only administrators can remove the setting via exchange or PowerShell, steps which are available on Microsoft’s official guide.
Consentfix risk can be amended – restricting or monitoring the device code as an authentication method
This can be an effective way of decreasing the risk of a simple MFA bypass via native authentication capabilities.
This is possible via conditional access policies. The advised exclusion or enablement of this feature would be for special cases such as a device with no display / CLI only or edge cases.
There are a few ways this can be applied, depending on the risk appetite of the business versus the internal need for the authentication method.
This can be applied by:
Blocking the authentication method globally & allowing for specific groups (e.g. IT, development) that are expected to use it or reviewed and allowed on a user-by-user basis via a top-level policy, which will take precedence over the global.
Time based access – a very good option as well, as it includes capabilities such as reviewing the access each time with justification, expires after x hours and can be applied to specific groups / users, as well.
If the review is not possible, the authentication method is trackable via Signin Logs so an alert, periodic checks or ad-hoc investigations are possible too. The AuthenticationProtocol == "deviceCode" should be appended to each session that utilizes it.
There are upsides and downsides to the restriction, the best option to take would depend on the environment, internal requirements and restrictions. As long as there is a clear understanding of the authentication method type and its legitimate use, companies can adopt the option that suits the internal use cases best.
Reference - https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows
Closing Statement
Even though the delivery is simple, the behavior it takes advantage of is not. By placing the interaction in the calendar, it aligns with how users already work to direct them to the malicious workflow while the ConsentFix technique legitimizes the workflow and lowers the guard of the target.
Meetings are expected, administrative alerts are acted on quickly and the content is presented in a way that does not feel out of place.
What does stands out more is the added visibility of the phish, persistence and the lighter scanning gap for invites. Even when the original email is handled, the event remains visible and continues to present/prompt the meeting with reminders.
That gap between delivery and artefact is where this becomes effective, and where it is currently harder to have that visibility and control.
