The IT Nerd

A critical attack chain has been found that completely bypasses Microsoft Entra ID Conditional Access without deploying malware or touching an endpoint. Using just a single set of credentials, the researchers compromised a production tenant with over 16,000 users.

Howler Cell conducted authorized red team operations against a production enterprise Microsoft Entra ID tenant (~16,000 users, ~82,000 devices, 78 Conditional Access policies). Starting from a single set of valid user credentials blocked by Conditional Access, the engagement produced a full bypass chain: 

• Phantom device registration
• Primary Refresh Token minting 
• Intune compliance without a real device 
• Enterprise application exfiltration 
• On-premises-to-cloud privilege escalation path mapped to Global Administrator.

No corporate endpoint was touched. No malware was deployed. The vulnerability is not in any single component. It is in the trust chain between them.

More details here: https://www.cyderes.com/howler-cell/azure-ad-conditional-access-device-identity-abuse

Ensar Seker, CISO at threat intel company SOCRadar, commented:

“The Howler Cell research highlights a dangerous reality many organizations still underestimate: identity has become the new perimeter, and attackers know how to abuse the trust built into cloud identity ecosystems. What makes this attack path especially concerning is that Conditional Access was technically functioning as designed, yet the attacker was still able to introduce a “trusted” phantom device into the environment and obtain a valid Primary Refresh Token. Once the identity system believes a device is compliant, many downstream protections effectively collapse.

This also demonstrates why organizations cannot rely solely on default Entra ID configurations or compliance states as proof of trust. Attackers increasingly target enrollment workflows, token issuance, and device registration processes because these areas often receive less scrutiny than endpoint malware defenses. Organizations should aggressively restrict device registration permissions, require hardware-backed authentication such as phishing-resistant MFA, continuously audit newly joined devices, monitor abnormal PRT issuance activity, and implement strong conditional policies around privileged access and unmanaged enrollment scenarios.”

Consider this to be your wake up call. Zero trust isn’t a buzzword, it should be a reality for you. And this red team exercise illustrates why.

On April 29, researcher Tom Jøran Sønstebyseter Rønning, posting as @L1v1ng0ffTh3L4N, presented findings showing that Microsoft Edge decrypts every saved password at startup and holds all of them in process memory, in cleartext, for the entire browser session. The researcher reports that this includes both passwords for sites the user is visiting and every credential the user’s ever saved. The passwords are held in memory from the moment Edge opens.

Uzair Gadit, Founder & CEO, Secure.com

“What makes this Edge finding unusual is not just the technical behavior, it is the assumption behind it. Users are told to follow best practices, use strong passwords and use a password manager, and they did. The problem is the software holding those credentials made a design decision that fundamentally changes the risk, and most users were never made aware of it.

“On its own, requiring administrative access might sound like a limiting factor. In reality, that’s exactly where many enterprise breaches begin. Once an attacker gains privileged access in a shared environment like RDS or Citrix, the difference between decrypting credentials on demand versus holding them all in memory becomes significant. It can turn a single compromised account into a broad credential exposure event across multiple users.

“This is where the cyber sector needs to shift its thinking. We have spent years telling users to improve password hygiene, but this isn’t a hygiene problem, it’s an exposure problem. The question is no longer just how strong a password is, but how long it exists in a usable state, where it exists, and who or what can access it there.

‘The architectural difference highlighted here is important: minimizing the time credentials exist in plaintext reduces risk. Keeping everything decrypted for convenience increases it. Both are intentional design choices, but only one aligns with how attackers increasingly operate, especially with automation and AI make it easier to move laterally once access is established.

“World Password Day tends to focus attention on user behavior. This is a reminder that the bigger risk often sits one layer below that, in the design decisions made by those producing the tools people are told to trust. If those decisions prioritize usability over exposure reduction, then even a user’s perfect password hygiene won’t consistently deliver the security outcome their organizations expect.

“The real takeaway isn’t that passwords are weak, it’s that credential exposure still isn’t being treated as a first-order risk in system design. Until that changes, attackers will continue to focus less on breaking in and more on taking advantage of what’s already available once they are inside.”

This is pretty bad and it is a epic problem that needs to be addressed. I would be very interested to see how Microsoft addresses this as they are the only Chromium based browser to have this issue.

Researchers have published new findings PhantomRPC: A new privilege escalation technique in Windows RPC on April 24^th about a  has no patch as it is said to be an architecture problem, and affects all Windows systems.

In response, three cybersecurity experts offer perspective.

Sameed Aijas Ahmed Khan with Dubai-based Secure.com:

“PhantomRPC is a meaningful finding because it sits at the architectural level of Windows, not in an isolated feature that can simply be switched off or patched. What makes it particularly relevant for organizations is the lateral movement risk. 

Once an attacker has a foothold, a flaw in how Windows systems communicate internally can become a pathway across the broader environment and that kind of silent spread is exactly what makes unpatched vulnerabilities so costly over time. We’ve written about how the Dell zero-day campaign went undetected for over 400 days precisely because the initial entry point wasn’t caught in time.

Architectural changes are genuinely complex, and caution is understandable. But as we’ve covered in looking at the Microsoft Word zero-day earlier this year, the window between disclosure and active exploitation tends to be short and organizations are left managing that risk largely on their own.

When remediation isn’t immediately available, mitigation becomes the working strategy. That means network segmentation to limit unnecessary exposure, tightening access controls around privileged accounts, and increasing monitoring for anomalous behavior in affected systems. As we note in our coverage of vulnerability remediation vs. mitigation, a mitigated vulnerability is still present so the goal is to reduce the blast radius while staying alert to how the situation evolves.”

Jacob Krell, Senior Director, Secure AI Solutions and Cybersecurity, Suzu Labs:

PhantomRPC can turn a lower-privileged service compromise into SYSTEM-level control. For an organization, that means a normal foothold can become full host compromise. From there, an attacker may be able to access sensitive credentials, tamper with security tooling, establish persistence, and use the machine as a staging point for lateral movement. The important point is that this is not just a single bad component. Kaspersky’s research points to a broader weakness in how Windows RPC handles server provenance, which means new abuse paths may continue to appear as researchers and attackers find additional privileged RPC clients.

Microsoft’s decision not to issue a patch makes sense only within a narrow vulnerability-triage model. The issue typically requires SeImpersonatePrivilege, and Microsoft appears to have treated that prerequisite as a limiting factor. The problem is that SeImpersonatePrivilege has been central to Windows privilege escalation research for years. It is not rare, exotic, or purely theoretical. Many real-world compromises already land in service contexts where impersonation privileges are available by design.

That is especially important because service accounts are often one of the first positions an attacker obtains after exploiting a web-facing application or local service. From an attacker’s perspective, the question after that initial foothold is simple: how do I become SYSTEM? PhantomRPC provides one answer by abusing the trust relationship between privileged RPC clients, expected endpoints, and impersonation. That makes the prerequisite less reassuring than it may appear on paper.

Microsoft should remediate the underlying architectural weakness, or at minimum provide stronger platform-level safeguards around RPC endpoint authenticity and privileged impersonation flows. The lesson from the Potato family was that broad impersonation rights can turn service-level access into SYSTEM. PhantomRPC shows that lesson still applies, just through a different IPC path. A flaw that repeatedly converts common service compromise into full host control should not be dismissed simply because the dangerous privilege was granted by design.

To protect themselves, organizations should focus on detection, hardening, and reducing unnecessary impersonation exposure. Kaspersky’s recommended approach is ETW-based monitoring for RPC activity where high-privileged clients attempt to connect to unavailable servers, especially when those calls use elevated impersonation levels. Those failures can indicate places where a malicious RPC server could be inserted.

They should also review which custom and third-party services hold SeImpersonatePrivilege and remove it where it is not strictly required. Where possible, legitimate services should be configured so expected RPC endpoints are actually registered, reducing the opportunity for an attacker to occupy the missing endpoint first. This is not a complete fix, but it reduces the attack surface and gives defenders observable signals.

PhantomRPC should be viewed in the same lineage as the Potato family of Windows privilege escalation techniques. Those exploits showed years ago that service accounts with SeImpersonatePrivilege can become a dangerous bridge to SYSTEM when Windows allows a lower-privileged process to impersonate a higher-privileged caller. PhantomRPC matters because it shows that the underlying design issue was never fully eliminated. The abuse path has moved from familiar COM-based techniques into the RPC layer itself.

That is why treating SeImpersonatePrivilege as a simple prerequisite misses the larger point. The privilege is widely granted to service identities because Windows services need impersonation for legitimate functionality. In practice, that makes it part of the operating system’s architectural attack surface, not an unusual edge condition. If a common service context can register the right endpoint, wait for a privileged client, and inherit its authority, the weakness is in the trust model around impersonation and endpoint provenance.

This is also unlikely to be the last route researchers find. Once the pattern is understood, the question becomes how many other privileged Windows clients connect to expected IPC endpoints without strong enough assurance about who is actually listening. Security teams should treat PhantomRPC less like a one-off vulnerability and more like a signal that Windows IPC and impersonation flows need sustained monitoring, hardening, and architectural attention.

Xcape, Inc. board member Damon Small:

Microsoft’s decision not to patch is technically defensible under their traditional servicing criteria – since the attacker already needs SeImpersonatePrivilege – but it is operationally negligent in a landscape where attackers frequently use compromised service accounts as a beachhead. This “Moderate” rating ignores how easily these prerequisites are met during real-world lateral movement. Since no patch is forthcoming, defenders must treat this as a permanent architectural debt. To be clear, it is not so much that Microsoft decided not to patch, but at this time it appears that it cannot be patched without fundamentally changing how RPC functions.

The most effective mitigation organizations should invoke is to restrict SeImpersonatePrivilege to the absolute minimum number of accounts and utilize Host Intrusion Prevention Systems (HIPS) or EDR rules to monitor for unauthorized processes attempting to bind to known RPC ports, particularly those associated with the Terminal Services port range.

This was reported to Microsoft on September 25, 2025. Microsoft assessed this as a moderate severity, not eligible for a bug bounty, and not in need of a CVE or immediate fix at the time. Because of the fundamental, architectural, nature of this vulnerability, we should expect to see variants on this attack pattern emerge in the future. Defenders should keep an eye on service accounts exhibiting anomalous behavior, such as spawning arbitrary listeners. This publication at this time is indicative of a pattern where Microsoft has downplayed an external researcher’s finding because resolving the underlying issue is a deep architectural change. It is a bold strategy for Microsoft to claim a flaw is not a bug simply because you have to be halfway into the house before you can use it to unlock the safe.

I strongly recommend that you read this report and consider this to be a “today” problem because there is no fix. Which means that it’s only a matter of time for threat actors exploit this if they have not already.

I have received two calls today about people having issues with Outlook.com email accounts (which can be also hotmail.com). Here’s what they are reporting:

• Outlook on iPhone is making users sign in.
• You go through the steps to sign in and you still get a prompt to sign in.
• Removing and re-adding the account does not fix this. Mi

I’ve been able to replicate this myself.

This issue seems to be widespread based on Down Detector which has similar reports of this issue. Microsoft’s Service Status page as well as on Twitter confirm this as well:

Thus it is safe to say that Microsoft has an issue that it is trying to wrap its hands around. There does not appear to be an ETA to resolution. Thus users of Outlook.com will have to wait it out until Microsoft fixes this.

Microsoft has warned that threat actors are operationalizing AI along the cyberattack lifecycle to accelerate tradecraft, abusing both intended model capabilities and jailbreaking techniques to bypass safeguards and perform malicious activity. They’re embedding AI into their workflows to increase the speed, scale, and resilience of cyber operations, with the most malicious use of AI centering on using language models for producing text, code, or media.

Microsoft Threat Intelligence has observed that most malicious use of AI today centers on using language models for producing text, code, or media. Threat actors use generative AI to draft phishing lures, translate content, summarize stolen data, generate or debug malware, and scaffold scripts or infrastructure. For these uses, AI functions as a force multiplier that reduces technical friction and accelerates execution, while human operators retain control over objectives, targeting, and deployment decisions.

This dynamic is especially evident in operations likely focused on revenue generation, where efficiency directly translates to scale and persistence. To illustrate these trends, this blog highlights observations from North Korean remote IT worker activity tracked by Microsoft Threat Intelligence as Jasper Sleet and Coral Sleet (formerly Storm-1877), where AI enables sustained, large‑scale misuse of legitimate access through identity fabrication, social engineering, and long‑term operational persistence at low cost.

More details can be found here: https://www.microsoft.com/en-us/security/blog/2026/03/06/ai-as-tradecraft-how-threat-actors-operationalize-ai/

Ensar Seker, CISO at SOCRadar:

“AI is rapidly becoming embedded across the entire cyberattack lifecycle, but not always in the ways people expect. In many cases, threat actors are not building their own advanced AI models; instead, they are operationalizing existing generative AI tools to accelerate traditional attacker workflows. We are seeing AI used to scale reconnaissance, generate convincing phishing content in multiple languages, automate vulnerability research, and refine social engineering campaigns. The real shift is not sophistication alone, it is the speed and scale at which attackers can now execute tasks that previously required significant manual effort.

“The biggest impact of AI in cyber operations is efficiency rather than completely new attack techniques. Attackers are using AI to shorten the time between reconnaissance and exploitation. For example, AI can help analyze large datasets of leaked credentials, generate exploit scripts, or summarize technical documentation for vulnerabilities. This lowers the barrier to entry for less experienced actors while allowing more advanced groups to increase operational tempo and run campaigns in parallel across multiple targets.

“However, AI does not replace traditional attacker tradecraft or eliminate the need for human expertise. Sophisticated campaigns, especially those conducted by nation-state groups, still rely heavily on manual reconnaissance, custom tooling, and operational security discipline. AI is acting more as a force multiplier than a replacement for established tactics. Threat actors still need access, infrastructure, and a clear objective; AI simply helps them move faster once those elements are in place.

“For defenders, the most important takeaway is that AI-driven attacks will increasingly look more polished, personalized, and scalable. Security teams should expect a rise in high-quality phishing, automated reconnaissance against external assets, and AI-assisted malware development. The response should not be panic about AI itself, but investment in visibility, especially around identity, external attack surface, and threat intelligence, so organizations can detect attacker activity early in the intrusion lifecycle before AI-assisted campaigns gain momentum.”

Martin Jartelius, AI Product Director at Outpost24:

“We are seeing the same trend in our own research. In one recent investigation, we observed a threat actor using ChatGPT to assist with vulnerability research related to potential zero-day exploitation. In this case, the attacker’s operational security was weak enough that their activity left a visible trail, giving us rare insight into how generative AI is being used as a ‘research assistant’ during attack preparation. What this highlights is that AI is increasingly acting as a force multiplier for attackers, accelerating reconnaissance, scripting, and vulnerability analysis while lowering the technical barrier to entry.”

AI can do a lot of cool things. But it can also do a lot of bad things if given the chance to. This illustrates the fact that those who defend against attacks should expect more attacks than ever before. Which is of course a bad thing.

Microsoft is investigating reports of 504 Gateway Timeout errors impacting US-based Microsoft 365 users trying to access services that require Multi-Factor Authentication (MFA).

Darren James, Senior Product Manager at Specops Software, provided the following comments:

“This event highlights the importance of having a flexible MFA policy that doesn’t rely on a single second factor. Of course you do need to consider the relative strength of alternate authentication factors, for example an SMS OTP is certainly not as strong as a biometric authentication. However, a layered approach, such as using a trusted device that allows you to pin your users identities to the specific devices they use, along with making sure those devices meet your organization’s posture requirements, will give you the ultimate flexibility when it comes to balancing business security, business continuity and user experience.”

This is a good point as most organizations MFA setups only rely on one second factor. Having multiple options makes something like this less of an issue, if not a non issue. Thus this situation should be a lesson to make that move as soon as possible.

It is being reported hackers are targeting technology, manufacturing, and financial organizations in campaigns that leverage device code phishing with voice phishing (vishing) to abuse the OAuth 2.0 Device Authorization flow and compromise Microsoft Entra accounts.

Unlike previous attacks that utilized malicious OAuth applications to compromise accounts, these campaigns instead leverage legitimate Microsoft OAuth client IDs and the device authorization flow to trick victims into authenticating.

This provides attackers with valid authentication tokens that can be used to access the victim’s account without relying on regular phishing sites that steal passwords or intercept multi-factor authentication codes.

Ensar Seker, CISO at SOCRadar, commented:

“This campaign is significant because it doesn’t break authentication, it abuses it. The OAuth 2.0 Device Authorization flow was designed for usability across limited-input devices, but attackers are now socially engineering users into completing legitimate device login prompts under the guise of IT support or security validation. By leveraging real Microsoft OAuth client IDs instead of malicious apps, adversaries avoid many traditional detection controls. The result is a valid authentication token issued by Microsoft itself, which means no password theft, no MFA bypass exploit, just human manipulation.

“What makes this especially dangerous for enterprises is that many security programs still focus heavily on credential phishing indicators, fake domains, cloned login pages and MFA fatigue. Device code phishing shifts the battlefield into token abuse and session hijacking. Once the attacker has a valid access token tied to Entra ID, they can move laterally into M365, SharePoint, Teams, and potentially pivot toward financial fraud or data exfiltration without triggering obvious alerts.

‘If ShinyHunters is indeed involved, it signals continued evolution from traditional data-theft extortion toward identity-centric compromise models. Identity is the new perimeter, and OAuth abuse is becoming a preferred entry point because it blends into normal authentication telemetry.

“From a defensive standpoint, organizations need to restrict or monitor the Device Authorization flow where not required, enforce Conditional Access policies that bind tokens to compliant devices, reduce token lifetimes, enable sign-in risk policies, and implement stronger session monitoring. Security teams should also train employees that legitimate IT will never ask them to manually enter device codes shared over the phone.

“This is not a vulnerability in Microsoft Entra, it’s a design feature being exploited through social engineering. The real lesson is that modern attacks increasingly weaponize legitimate cloud workflows rather than exploit technical flaws.”

This is a very good time to start looking at your Microsoft Entra setup to make sure that you are not vulnerable. Because now that this is being used by one group of threat actors, it will be used by others soon enough.

Disclaimer: I am not trying to give tips to the bad guys. But given the fact that I have been emailed about this repeatedly since this story broke, I felt that I needed to respond.

Late last week, news broke that Microsoft not only will hand over Bitlocker keys to law enforcement, but it has done so.

Wait, what are Bitlocker keys? Glad that you asked that question.

Microsoft Windows 11 has a full disk encryption feature called Bitlocker. The goal of Bitlocker is to keep your data on your laptop or desktop safe by encrypting it. And to decrypt it, you need a key to do that. So think of it like this. Your data is protected by a padlock. And you have a key to unlock it. That should keep it save from prying eyes.

But here’s the catch, Microsoft also has a key to your data and is willing to hand it over to law enforcement. Now this is likely making you think “wait, I didn’t give Microsoft a key to my data”. Well, actually you did. If you install Windows 11 and you turn on Bitlocker, assuming that it isn’t on already, you need to create a Microsoft account. The idea is that it will store the Bitlocker key in the cloud. The thing is, that the second you do that, Microsoft has access to that key. Now you can opt out of this, but it takes a lot of effort (the cynic in me says that this is deliberate on the part of Microsoft) to do that. And the average user isn’t going to go through that effort. So they take the easy way out.

If you’re still with me, you’re now likely thinking “wow, that’s a massive potential security risk for users.” And you’d be right. The fact that Microsoft can do this to anyone who uses Windows 11 with a Microsoft account is problematic to say the least. Contrast that with Apple who claims to have zero access to keys related to FileVault which is their full disk encryption feature, it creates a comparison that I am going to guess that Microsoft would rather you not make.

So, if this freaks you out, the question becomes what are your options to mitigate this risk. This is what I would suggest:

• Use A Local Account Instead Of A Microsoft Account: By installing Windows 11 with a local account, you avoid this completely as it doesn’t upload the Bitlocker keys to the cloud where Microsoft can get access to them. Microsoft shockingly has instructions as to how to do this here. But I would default to these instructions as they are a bit more straightforward.
• Don’t Use Bitlocker To Encrypt Your Disk: Alternatives to Bitlocker that I would actually recommend to people are few and far between. What I would recommend instead is using a self encrypting hard drive. The reason being is that Bitlocker is largely software encryption. That means that there is a bit of overhead in terms of the data being encrypted and decrypted. A self encrypting hard drive is hardware encryption which has substantially less overhead. Another plus that self encrypting drives have over Bitlocker is that these drives secure data in ways that make them difficult if not impossible to break into. Self encrypting drives can be installed in most laptops and desktops after purchase, or they can be added as options during the purchase process. Besides speed, these drives also adhere to standards such as FIPS 140-2 Level 3 validation. Which makes them ideal for environments where the security of data is paramount. The only thing that I would ensure is that you should make sure that the drive that you use adheres to the TCG Opal 2.0 specifications for maximum compatibility with applications that manage these drives. If you want to go down the rabbit hole on self encrypting drives, this will help you to do so.

Now should you worry about the fact that Microsoft will hand over your Bitlocker keys to law enforcement? One view is that if you’re not a bad guy you shouldn’t be concerned. Another view is that if you care about privacy, you should be concerned as someone outside of Microsoft might get their hands on these keys and use them for whatever evil purpose that they have in mind. Or Microsoft may start handing these keys over to non-law enforcement agencies or repressive governments or the like. The bottom line is that you have to look at this relative to your comfort level of letting Microsoft have access to the keys that protect your data. And take action based on that.