The IT Nerd

In a statement published yesterday, Microsoft warned that recent public disclosures of unpatched zero-day vulnerabilities without prior coordination have placed customers at “unnecessary risk.”  The company said several researchers disclosed vulnerability details publicly before Microsoft had an opportunity to develop and distribute security fixes.

The company said coordinated vulnerability disclosure allows vendors time to investigate reports, prepare mitigations, and release patches before technical details become widely available to attackers. Microsoft argued that premature disclosure can increase the likelihood of exploitation against customers who have no available patch or remediation at the time information becomes public.

The warning comes as Microsoft continues addressing multiple recently disclosed vulnerabilities across Exchange Server, Defender, Azure, Windows networking components, and enterprise products during an unusually high-volume patching cycle. Microsoft released fixes for 138 CVEs during May Patch Tuesday alone, while additional vulnerabilities and mitigations were disclosed outside the regular patch release schedule.

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

   “Coordinated disclosure is a shared obligation. Microsoft generates hundreds of billions in annual revenue. No researcher should be expected to subsidize product security for free. Six vulnerabilities across core Windows components including Defender and BitLocker that reached production represent a vendor engineering failure. These flaws should never have shipped. Vendors who ask for coordination must also invest in responsive triage and the development rigor that prevents this.

   “The traditional 90 day embargo was designed for a slower world. AI has compressed vulnerability discovery timelines so dramatically that ninety days is enough time for an entirely new frontier model to be deployed and pointed at the same codebase. Microsoft has patched over 500 CVEs in the first five months of 2026 alone. That volume is a signal that product security posture across the ecosystem is weaker than the market assumes. The Nightmare-Eclipse campaign has followed through on every public threat so far, and the warnings of further disclosures should be taken seriously.”

John Carberry, Solution Sleuth, Xcape, Inc.:

   “Microsoft’s sharp public rebuke against zero-day drops highlights an escalating war of attrition between independent researchers and enterprise vendors. While Microsoft argues that dropping vulnerabilities like RedSun, UnDefend, and BlueHammer puts the entire ecosystem at risk, this friction points to a deeper systemic breakdown. The security research community is clearly growing frustrated with vendor triage timelines, a bottleneck that has become critical given that Microsoft is already drowning in an engineering workload, evidenced by a massive 138-CVE patch cycle this month alone.

   “For enterprise risk leaders, this public spat is a dangerous distraction from the actual operational threat. The moment a researcher publishes full technical details or a working proof-of-concept for core Windows components like Defender, Azure, or Exchange Server, the time-to-exploit window for threat actors drops to zero.

   “Security executives cannot afford to wait around for vendor patches to slowly wind their way through QA and deployment pipelines. They must establish an aggressive, internal mitigation capability that treats uncoordinated disclosures as immediate, active incidents, forcing them to deploy temporary configuration workarounds and hyper-specific EDR detection rules the moment a flaw hits GitHub, long before the official automated fix arrives on a future Patch Tuesday.

   “Critical Takeaways

•    “The zero-day names to watch: The uncoordinated drops specifically targeting core architecture(RedSun, UnDefend, BlueHammer, and the YellowKey BitLocker bypass) are not theoretical exercises. They represent immediate blueprints that threat actors are actively integrating into automated scanning tools.
•    “Vendor triage under siege: Microsoft’s massive 138-CVE May release proves that vendor patch pipelines are stretched to their limits, systemically increasing the delay between a researcher’s initial private bug report and a public patch.
•    “The mitigation engineering mandate: Relying entirely on automated patch management leaves an enterprise completely exposed during uncoordinated drops. Teams must be structurally capable of manually applying complex, out-of-band scripts and registry mitigations.

   “When researchers choose to drop working exploit code for core enterprise infrastructure directly to the public, they are giving the entire Internet an immediate, unauthenticated pass into your network before a lock has even been engineered.

   “The current standoff proves that the traditional model of coordinated vulnerability disclosure is buckling under its own weight, leaving enterprise security teams stuck in the crossfire between impatient researchers and overextended software vendors.”

Lydia Zhang, President & Co-Founder,Ridge Security Technology Inc.:

   “The number of CVEs patched by Microsoft on Patch Tuesday highlights the challenge facing security teams which is, what should I be prioritizing?   Security tools that just identify vulnerabilities are insufficient.   In fact, even knowing that a vulnerability is exploitable is insufficient.  Knowing the kill-chain is insufficient.  The missing piece of the puzzle is combining that exploitability and kill-chain knowledge with business context such as what assets can be reached thru these exposures and how valuable are those assets?”

My only advice is to hold companies like Microsoft accountable. Otherwise we will have vendors deciding what is and isn’t public domain. Which is of course dangerous.

So over the last few days, the Internet has been losing its mind over the fact that Microsoft on July 13 2026, Microsoft Office 2021 and 2019 for Mac will only be able to open files. But they cannot save them. This is documented here. And the reason for this is an expired certificate. If you want examples of how people are losing their minds over this, take this Reddit thread or this one to see what I am talking about.

But is the outrage justified? I am not sure because I can see this from both sides.

On one hand, Office 2019 for Mac has reached the end of support in October 2023. That means that it is not receiving security updates or bug fixes. Office 2021 for Mac will be in the same state in October 2026. So users realistically should be installing either Office 2024 or using Microsoft 365 as it’s never a good idea to run unsupported software as that’s a gateway for threat actors to pwn you.

On the other hand, many people on Reddit feel that this is anti consumer as comes across Microsoft deciding to effectively kill a license that they paid for. Also they feel that Microsoft could easily come out with a software update that addresses the certificate issue. But clearly they don’t want to do that. And forcing users to pay for an upgrade is good for Microsoft’s bank account.

Mac users have a few choices if they are in this situation:

• Upgrade to Office 2024 or Microsoft 365. I should note that Microsoft 365 is currently free via the web version of the suite. So that’s a free alternative if you have constant access to the Internet.
• Use Apple’s iWork suite as it is free for normal use.
• Switch to an open source alternative such as LibreOffice. 

A few random thoughts. I have said for years that that hell hath no fury as an Apple user scorned. Microsoft may be about to find this out shortly as this is unlikely to go away. Also, these Mac users who are outraged need to recognize that there are options for them and they should look into those alternatives ASAP. Because running these versions of Office is not going to be an option.

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.