Microsoft resolved a Windows 11 issue that blocked non-admin users from connecting via Remote Desktop when Administrator protection was enabled, releasing fixes on October 28, 2026, for connection failures with error 0xC000000D.

The bug appeared after the September 22 non-security preview update, KB5124010, or later updates. Affected users could see the message, “The token that was passed to the function is invalid.”

Microsoft’s release health notice identifies enterprise-managed computers acting as Remote Desktop hosts as the main systems affected.

Microsoft opened its investigation on October 13. As detailed in Cyber Security News’ earlier coverage of the Remote Desktop connection failures, the problem prevented standard users from reaching remote systems where Administrator protection was active. The failure could occur regardless of how administrators enabled that feature.

Microsoft lists Windows 11 versions 24H2, 25H2, 26H1, and 26H2 as affected platforms. Its notice does not list Windows Server as affected by this particular issue. That scope matters because other recent Remote Desktop problems have involved different Windows releases and separate update failures.

Administrator protection limits how applications gain administrator rights. Instead of leaving those rights available throughout a session, it grants temporary access for approved tasks.

Microsoft Fixes Windows 11 Remote Desktop Failures

Cyber Security News’ explanation of Windows 11 Administrator protection describes how this approach helps reduce the risk of malware making unwanted system changes.

The setting may already be active in managed environments. Microsoft says its Windows 11 24H2, 25H2, and 26H2 security baselines enable Administrator protection by default unless an organization changes the policy. Businesses using those baselines should therefore check affected hosts rather than assume the feature was never enabled.

According to Microsoft’s release health advisory, updates released on or after October 28 resolve the issue. Systems running an applicable fixed update no longer need the temporary workaround. Microsoft recommends installing the latest security update available for the device to receive relevant fixes and improvements.

The KB5127936 release notes explicitly confirm the Remote Desktop repair. This non-security preview update applies to Windows 11 25H2 and 26H2, raising their builds to 26200.9818 and 26300.9818, respectively.

Administrators managing other affected versions should check the package offered for their specific Windows release instead of treating KB5127936 as a universal installer.

For affected computers still running older updates, Microsoft allows administrators to temporarily turn off Administrator protection through their existing management tools. The documented workaround involves resetting the “User Account Control Type Of Admin Approval Mode” policy through Microsoft Intune or Group Policy.

Because this workaround turns off a security feature, it should remain temporary. After deploying the appropriate fixed update, IT teams should verify Remote Desktop access using a non-admin account and review any policy changes made during troubleshooting. This confirms remote access works without leaving the earlier workaround in place unnecessarily.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Microsoft Fixes Remote Desktop Connection Failures Following Recent Updates appeared first on Cyber Security News.

Microsoft urged Entra ID administrators to migrate from SMS and voice authentication in Entra ID to passkeys before retirement begins on February 1, 2027, to reduce phishing risks and prevent sign-in disruptions.

The reminder, published on October 27 under Message Center notice MC1528000, follows July announcements. Retirement covers Worldwide and Government Community Cloud environments and should finish in early February 2027. Administrators should not wait until the change reaches their tenant before preparing affected users.

According to the Microsoft retirement notice, users with another registered sign-in method will use that method. They will not need to register a passkey to continue accessing their accounts. This makes checking existing authentication methods an important first step for administrators.

Users whose only registered method is SMS or voice face a different process. Microsoft says they can use their existing method one final time to verify their identity. They must then register a passkey to keep signing in, making preparation important for organizations with many phone-dependent accounts.

The announcement continues the shift covered in Cybersecuritynews.com’s report on Microsoft making passkeys the default in Entra ID. However, this retirement applies specifically to Microsoft-provided phone authentication, not a complete ban on SMS and voice across Entra ID.

Microsoft Urges Passkey Migration

SMS and voice authentication remain exposed to phishing and SIM-swap attacks. Criminals can trick users into sharing verification codes or take control of an authentication phone number. Moving away from these methods reduces reliance on phone networks and codes that attackers can capture.

As Microsoft’s passkey documentation explains, passkeys use public-key cryptography under FIDO standards. The user’s authenticator keeps the private key, while the service stores the public key. During sign-in, the authenticator signs a challenge after the user unlocks it with a PIN or biometric check.

The credential works only with the website or application it was created for, helping prevent fake login pages from stealing reusable sign-in secrets. Cybersecuritynews.com’s coverage of UNC3944’s SIM-swap attacks shows why reducing dependence on phone-based verification matters.

Administrators should identify users relying on SMS or voice, prioritize accounts without another registered method, and help users adopt passkeys or another supported option. Microsoft also asks organizations to notify employees and helpdesk teams about the deadline and the registration process.

Organizations that need to retain phone authentication can configure a customer-managed telecom provider through the Microsoft Security Store.

Microsoft’s provider guidance says configuration will be available starting October 30, 2026. Customers must review coverage, pricing, support, and contractual terms before deployment.

Existing customer-managed providers are unaffected. Organizations that do not use Microsoft-provided SMS or voice need no action for this retirement. At the same time, affected customers must migrate or configure their provider before February 1.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Microsoft Urges Entra ID Admins to Migrate from SMS and Voice Authentication to Passkeys appeared first on Cyber Security News.

A new exploit chain for Microsoft Edge revealed that combines five bugs and two Windows features to run code outside the browser sandbox.

Published by Security researcher Orange Tsai on October 28, 2026, the research shows how flaws in browser logic can turn a malicious webpage into code execution on Windows without memory corruption.

Tsai, a member of DEVCORE, built the chain for Pwn2Own Berlin 2026. His technical write-up describes two months of research completed without AI tools. The finished exploit used fewer than 100 lines of code.

The chain began in Edge’s Conditional Access navigation handler, which helps users switch to the right browser profile when accessing Microsoft services. When the supplied email matched the current profile, the handler started a new navigation using a supplied destination.

The crucial flaw was failing to bind that navigation to its original tab. Instead, Chromium used the active tab, letting JavaScript intended for one context run on another website. This created universal cross-site scripting, or UXSS, which breaks the boundary that normally keeps websites apart.

Microsoft Edge Zero-Click Exploit

Because the navigation came from the browser process, Tsai said that it could also bypass Content Security Policy protections. However, several checks still stood between this finding and an automatic attack.

First, Edge checked whether navigation came from a trusted Microsoft site, but failed to account for another window controlling that navigation. A cross-window flow bypassed this check. Separately, a hardcoded popup exception allowed the researcher to open a window without the usual user click.

The chain also needed a signed-in Edge profile and its email address. In the tested setup, Microsoft’s OneAuth feature could automatically create and sign in a profile using an existing Microsoft account when visiting a Microsoft website.

A cross-origin resource sharing misconfiguration on assets.msn.com then exposed the signed-in email to another website. Together, these steps removed the need for further clicks after attacker-controlled content loaded. The zero-click label therefore describes the automated chain, not an attack requiring no exposure to malicious web content.

Running JavaScript across websites was not enough to execute Windows code. Tsai next targeted Edge’s Immersive Reader, whose read:// address scheme was missing from the list blocking JavaScript URLs on privileged browser pages.

This exposed a native feedback function that packaged diagnostic logs. Path traversal and null-byte handling let the researcher write files outside the intended temporary folder and remove the enforced JSON extension. Cybersecurity News previously covered the related Edge feedback-log code execution vulnerability.

Tsai then changed protocols.json, an Edge configuration file controlling which websites may launch external protocol handlers. This allowed a webpage to invoke the Windows telnet handler. By placing a small executable in a writable directory Windows searches, he achieved code execution outside Edge’s sandbox.

Unlike the separately reported Edge memory-corruption vulnerability, this chain relied on logic errors and trusted features working together.

It shows why browser security reviews must test how navigation, identity, privileged pages, and Windows integrations interact, rather than checking each feature alone. Users should keep Edge updated through Microsoft’s security releases and avoid treating browser isolation as a complete defense.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Microsoft Edge 0-Click Exploit Chains Five Flaws to Execute Code and Escape Sandbox appeared first on Cyber Security News.

Microsoft released emergency Windows trust updates after discovering eight recoverable eMudhra intermediate CA private keys that could let attackers forge trusted certificates or sign malicious content.

Microsoft said the issue affected eMudhra’s certificate hierarchy, not Microsoft systems. The response includes an October 26 out-of-band Windows update removing seven certificates from the Windows trust list.

Microsoft confirmed on October 27 that it had removed the same certificates from the Microsoft Edge trust list, extending its response beyond earlier blocks against the compromised intermediates.

Six affected keys relate to Transport Layer Security, or TLS, which helps protect connections to websites and services. The other two relate to code signing, which helps systems check who published software. Recovering these keys could let attackers misuse the trust attached to their certificate authorities.

An attacker using a compromised TLS key could create a certificate to impersonate a website or service and potentially intercept communications. The code-signing keys could make malicious software appear to come from a trusted publisher. These are potential uses of the keys, not proof that such attacks occurred.

Microsoft Updates to Block eMudhra Certificates

Cyber Security News previously covered the eMudhra certificate authority compromise and the blocks introduced across major platforms. Its reporting on abuse of Microsoft Artifact Signing also shows why a trusted software signature does not guarantee that a file is safe.

Microsoft first updated the Windows Disallowed Certificate Trust List on October 20 to block the affected certificate authorities. It also deployed a separate CRLSet update for Edge and WebView2 to block affected TLS certificates. That browser protection arrives automatically through component updates without requiring a new browser version.

The later Windows update removes six eMudhra G3 root certificates and an AAA Certificate Services cross-sign. Removing these seven certificates is a broader trust decision, separate from blocking the eight compromised intermediate keys and from eMudhra’s revocation of the affected intermediate certificates.

Microsoft warned against restoring trust locally without assessing the risks. Software that does not reliably check certificate revocation or Microsoft’s disallowed list could still accept certificates linked to the compromised intermediates if the removed trust is retained or restored.

Organizations should allow Windows certificate trust updates and Edge component updates to reach managed devices. Disconnected Windows systems need special attention because administrators must provide an alternative way to update.

Microsoft’s certificate trust guidance explains how to distribute trusted and disallowed certificate lists through internal infrastructure.

Microsoft also urged customers to review disconnected Azure virtual machines and Virtual Machine Scale Sets. Updated images are available through Azure Marketplace.

Certificate owners should identify chains that depend on the seven removed certificates and obtain replacements or an alternative trusted chain.

Microsoft is evaluating remaining eMudhra roots separately as customers move away from affected hierarchies. Administrators can monitor Microsoft Trusted Root Program announcements for published changes and verify that certificate updates reach every managed system.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Microsoft Releases Emergency Windows Updates to Block Compromised eMudhra Certificates appeared first on Cyber Security News.

Microsoft patched high-severity flaw CVE-2026-80097 (CVSS 8.6) in Authenticator for Android, allowing malicious apps with no declared permissions to steal work account access tokens due to improper authentication in its broker component.

Microsoft classified the flaw as a local elevation-of-privilege vulnerability. The issue affected Android devices with Microsoft Authenticator installed and a signed-in work account.

Enclave researchers found that an untrusted app could pretend to be a trusted Microsoft application, such as Microsoft Teams, and ask Authenticator to issue delegated tokens for that identity.

The request did not need user approval, account credentials, or Android permissions beyond being installed on the device. At the center of the bug was an exported Android activity named com.microsoft.identity.client.AccountChooserActivity.

Other apps can start exported activities on the same device. In this case, the activity accepted a broker request from the calling app. It returned the authentication result after processing it.

The key problem was how Authenticator verified the requesting application. The broker request included the claimed app package name, client ID, redirect URI, requested scopes, and even a caller UID value.

Microsoft Authenticator Flaw

Enclave researchers reported that the malicious application could supply these fields rather than having them tied to the app that actually launched the request.

Authenticator did perform a signature-related redirect URI validation. However, the check focused on the app identity claimed in the request.

If the attacker claimed to be Teams, the vulnerable logic checked whether the redirect URI matched the real installed Teams package. Because Teams was legitimately installed, the attacker could build a valid redirect URI from its public package signature and pass the check.

In short, the app verified whether the claimed identity looked valid, but did not confirm that the real caller was the app it claimed to be. The vulnerable activity could identify the package that launched it, according to the research. However, it did not use that information to control trust.

Successful requests returned token data through the activity result bundle. The tokens could include access tokens, refresh tokens, ID tokens, and client information.

Depending on the impersonated Microsoft client and requested permissions, the impact could extend to Microsoft Graph resources such as mailboxes, calendars, OneDrive files, SharePoint content, and Teams-related services.

The researchers demonstrated the risk by impersonating multiple Microsoft apps. A Teams identity requesting Microsoft Graph access could receive delegated permissions that let it read and write mail, send messages, access files, and modify calendars. This flaw is especially important for organizations that use Android devices to access Microsoft 365 workloads.

Microsoft fixed the issue in Microsoft Authenticator for Android version 6.2606.4246, which was released in July 2026. Organizations and individual users should update the app through Google Play as soon as possible and verify that managed devices are running a current release.

Microsoft’s advisory describes the issue as improper authentication that could let an unauthorized local attacker elevate privileges.

The flaw also highlights why mobile identity brokers must validate the real calling application, including its package identity, UID, and signing certificate, rather than relying on app-controlled values in an intent.

The incident highlights Microsoft’s ongoing efforts to protect Entra credentials on rooted Android and jailbroken iOS devices, where malware and weakened security controls increase enterprise identity risks.

Organizations should review mobile application controls, enforce timely app updates through MDM or EMM platforms, and restrict sideloaded applications where possible.

Security teams should also monitor unusual Microsoft Graph activity, unexpected consent behavior, and token use from unfamiliar Android devices. Microsoft’s official CVE-2026-80097 advisory should be used for ongoing remediation guidance.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post Microsoft Authenticator Flaw Lets Malicious Android Apps Steal Account Tokens With Zero Permissions appeared first on Cyber Security News.

Microsoft has introduced a new report-assessment system across its bug bounty programs, making the evidence security researchers submit a key factor in their rewards.

Under the Azure bounty program, eligible critical remote code execution and privilege escalation reports can earn $40,000 when assessed as Complete, compared with $4,000 when marked Not Complete.

The change applies to reports submitted from October 20, 2026, at 8 AM Pacific Time. Earlier submissions remain subject to the previous report quality requirements.

Microsoft says the update aims to reduce requests for missing details and help its security teams reproduce and assess vulnerabilities faster.

The $40,000 figure is not a standard payment for every Azure vulnerability. Microsoft’s Azure Bounty Program ties awards to security impact, severity, and report completeness.

Microsoft Offers $40,000 for Complete Azure Vulnerability Reports

Critical information disclosure reports carry general awards of $12,000 when complete and $1,200 when incomplete. Critical spoofing and tampering reports qualify for $8,000 or $800, respectively.

Important remote code execution reports can receive $30,000 when complete, against $3,000 when incomplete. Azure’s published award range remains $400 to $60,000, with additional rewards possible at Microsoft’s discretion. Certain high-impact scenarios also carry percentage increases.

A complete report does not automatically qualify for payment or make a vulnerability critical. Microsoft assesses severity and security impact separately. Azure submissions must also meet program rules, including demonstrating an eligible issue on the latest, fully patched service or product.

Microsoft expects clear reproduction steps, a reliable proof of concept, the vulnerability type, and accurate technical analysis. Researchers must identify the affected environment, relevant versions, attack requirements, and what an attacker could achieve. They should explain the root cause where possible.

The key test is whether an engineer unfamiliar with the finding can reproduce and assess it using the initial submission. Missing a required detail or supporting file can result in a Not Complete assessment, even if Microsoft later requests more information.

Evidence requirements depend on the vulnerability. Memory corruption reports may need crash data, call stacks, and proof-of-concept source code.

File redirection findings may require Process Monitor logs, while NTLM coercion or relay reports may need packet captures. Web application findings can require videos and scripts.

Researchers must enter reproduction steps and technical details directly into the MSRC Researcher Portal fields. An attached document does not replace those entries. Microsoft’s report completeness guidance explains the required evidence.

Microsoft says AI-assisted research makes it easier to submit potential findings at scale. It welcomes AI use, but reports must still contain accurate analysis and evidence that demonstrates the issue.

Previous reporting on Azure application spoofing flaws shows why the exact bypass matters. Researchers demonstrated how invisible Unicode characters could defeat restrictions on reserved application names.

Coverage of a Microsoft authentication flaw also illustrates the link between research, disclosure, and remediation. After receiving the report, Microsoft restricted the affected endpoint and awarded the researcher $5,000.

For researchers, the practical change is that documentation now carries a clear financial consequence. A valid finding needs a reproducible demonstration, supported technical claims, and the required files from the start. Testing must still stay within Microsoft’s rules rather than exceed permitted access simply to prove greater impact.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post Microsoft Offers $40,000 for Complete Azure Vulnerability Reports, Just $4,000 for Incomplete Ones appeared first on Cyber Security News.

A newly registered domain copies Microsoft Teams’ login page and interface, raising concerns about a phishing attempt targeting workplace users.

Security researcher Steven Lim reported that teams-cloud[.]live was just five days old when he flagged it on October 18, 2026. He urged organizations to block the address before employees encounter the fake site.

The alert highlights phishing built around a familiar business tool. A copied Teams screen could persuade employees to trust a sign-in request. However, the available report does not establish how many people visited the site, whether passwords were captured, or who operates the domain.

According to Steven Lim, the site mimics both the Teams login screen and its wider user interface. He said it resembles another example he shared on October 8, 2026. That similarity warrants investigation, but it does not confirm that the same attacker controls both sites.

Lim also reported that clicking an option to update Teams downloaded a TXT file. The alert does not provide the file’s contents, a hash, or evidence that it executes code.

Calling it confirmed malware would therefore go beyond the available findings. The unexpected download remains a useful detail for investigators checking browser activity and downloaded files.

Fake Microsoft Teams Domains Used to Steal Credentials

In a pinned comment supplied with the alert, Lim identified amgen[.]teams-cloud[.]live as a healthcare-themed target. The company name appears as a subdomain beneath teams-cloud[.]live. Its presence does not establish that Amgen was breached or that an employee account was accessed.

The concern is the gap between what users see and where they are browsing. A convincing Teams design does not make an unrelated domain a Microsoft service.

Cyber Security News previously covered attackers posing as IT help desk staff through Teams, pushing employees toward downloads or remote access. That separate activity shows how workplace trust can support phishing without a software flaw.

Another report examined fake login pages created through Teams redirects in browsers. No confirmed link exists to this domain, but both cases show why branding alone cannot validate a login prompt.

Defenders should review connections to teams-cloud[.]live and the reported subdomain, then check related downloads and sign-in activity. Lim specifically recommended Tenant blocking and web filtering.

Microsoft documents URL blocking through the Tenant Allow/Block List and custom domain blocking through Defender network protection. Administrators should apply controls suited to their environment and verify coverage rather than assume one setting blocks every route.

Employees should avoid the reported site and verify unexpected Teams update requests through their organization’s established IT support channel before entering passwords or opening downloads.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post Hackers Registered New Teams-Based Domains and Used a Login Page to Steal Your Logins appeared first on Cyber Security News.

Microsoft is investigating an Exchange admin center access issue that may prevent some administrators from opening the web portal used to manage Exchange Online. Affected admins may encounter an “Internal Server Error” message, according to the Microsoft 365 Status update provided for this report.

The company is tracking the incident under EX1500900 and has directed customers to the Microsoft 365 admin center for further information. The notice describes an access problem affecting some admins. It does not establish a global outage or confirm that users are unable to send and receive email.

“We’re investigating an issue in which some admins may be unable to access the Exchange admin center (EAC) and may encounter an ‘Internal Server Error’ message,” the supplied notice states.

Exchange Admin Center Issue

The Exchange admin center is Microsoft’s web-based console for managing Exchange Online. IT teams use it to manage mailboxes and groups, review mail flow reports, and handle migrations. Microsoft’s Exchange admin center documentation explains that available features depend on the administrator’s assigned roles and permissions.

Losing access can delay these tasks, particularly when teams need to review delivery problems or make urgent mailbox changes. However, an unavailable management portal does not, by itself, show that the underlying email service has stopped working. The supplied incident notice identifies admin access as the reported problem.

The brief announcement does not identify a root cause, affected regions, the number of impacted organizations, or a recovery timeline. It also does not announce a confirmed workaround. Those gaps mean the incident should not be described as a cyberattack or linked to a specific service change.

Administrators should check Health > Service health in the Microsoft 365 admin center and look for EX1500900. Microsoft’s service health guidance explains that this dashboard lists active incidents and advisories, with individual pages providing further details about each issue.

The Microsoft 365 Admin mobile app also supports service health updates and push notifications. This gives teams another way to follow Microsoft’s investigation without relying on the Exchange management interface itself. Updates should be checked against the incident record rather than inferred from reports about unrelated outages.

For essential work, Exchange Online PowerShell provides a separate command-line management interface. It supports Exchange Online administration, including security features. However, Microsoft’s supplied notice does not confirm that PowerShell is unaffected, so it should be treated as a possible alternative rather than a verified workaround.

Cybersecurity News previously covered a Microsoft Exchange admin center outage tracked as EX1051697. That incident involved HTTP 500 errors and reports of an alternative portal address helping some administrators. Those earlier findings do not establish a working fix for EX1500900.

The publication also reported a separate Exchange Online disruption tracked as EX1464935, which concerned broader service functionality. Its different incident number and reported impact underline why administrators should keep individual service events separate when assessing business disruption.

For now, the supported scope remains limited to the access failure described in the supplied announcement. Organizations should follow EX1500900 for confirmed impact, recovery progress, and any approved mitigation. Email delivery failures, if observed, need separate verification rather than being automatically attributed to this admin portal issue.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup into your SOC

The post Microsoft Exchange Admin Center Issue Blocks Web Portal Access to Admins With “Internal Server Error” appeared first on Cyber Security News.

Researchers uncovered a malware campaign that used a Microsoft-attested Windows kernel driver to turn off 145 antivirus and endpoint security processes, then stole passwords, cryptocurrency wallet data, browser sessions, and other sensitive information.

LastPass Threat Intelligence, Mitigation, and Escalation team, working with Delphos Labs, discovered the operation after attackers impersonated LastPass Authenticator through fraudulent GitHub pages.

The researchers track the information-stealing malware as Rapuncel. The campaign did not compromise LastPass systems, services, or customer vaults. Instead, attackers abused the LastPass name to make fake download pages appear legitimate in search results.

Victims searching for “LastPass Authenticator download” could find a fake GitHub organization designed to resemble an official product page. The page included LastPass branding, SEO-focused descriptions, and a download button.

Clicking the button redirected visitors through several GitHub Pages sites before reaching attacker-controlled infrastructure. The operators used hidden redirect GitHub pages and a Cloudflare-protected traffic layer to change payload servers without updating the public lure pages.

The final payload arrived as a large ZIP archive, sometimes larger than 100 MB. Researchers said the oversized archives contained junk files intended to exceed automated sandbox and scanning limits.

Microsoft-Signed Driver Enables Security Bypass

Inside the ZIP file, attackers included a renamed Microsoft debugging executable, vsdbg.exe, alongside a malicious vsdbg.dll. Windows loaded the malicious DLL through DLL side-loading, allowing the attackers’ loader to run under the appearance of a legitimate Microsoft component.

After gaining elevated privileges, the malware deployed a kernel driver named Alinubx.sys, saved as nvfsflt64.sys and registered as the “NVIDIA File System Filter Driver.”

The driver carried a Microsoft Windows Hardware Compatibility Publisher signature chain. That signature helped the malicious component appear trusted to Windows and security controls, despite its ability to kill security software.

The driver contained 145 hardcoded process names associated with antivirus and endpoint detection and response products. It used a kernel-level process termination mechanism to stop the targeted tools, including products protected by Windows Protected Process Light technology.

Researchers linked the driver to the CnCrypt or CcProtect driver line associated with Henan Dafeng Software. The attackers appear to have renamed the driver while retaining its dangerous process-killing capability.

The driver was not listed in Microsoft’s vulnerable driver blocklist when researchers checked it. Its clean or near-clean detection history also allowed it to evade signature-based defenses.

After it disabled endpoint tools, the Rapuncel stealer collected saved browser passwords from more than 25 browsers. It also targeted Chrome and Edge app-bound encryption through browser-process injection, allowing it to request password decryption from inside the browser process.

The malware also collected cryptocurrency wallet files, Discord tokens, Steam session data, Telegram information, Windows Credential Manager data, screenshots, and documents containing terms such as “password,” “seed,” “wallet,” and “recovery.”

Collected information was compressed into a ZIP file and sent to the reported command-and-control endpoint at 2.26.126[.]50.

According to a LastPass Threat Intelligence report, security teams should investigate systems showing the creation of the NvFsFilter service or writes to C:\Windows\System32\drivers\nvfsflt64.sys. Other key artifacts include \.\Alinubx, Alinubx.ccf, ProtectR3.dll, and Henan Dafeng Software in the driver-signing metadata.

IOC Type	Indicator	Description
SHA-256	611b3ba687b7f46319a19609605ddfe5225e6d85277d8e923eea3fdb6f7b5b61	Alinubx.sys malicious kernel driver
SHA-256	aefbc6e04320e9a0e80f2323f8a897c4fdb222a37b0b87d76e850109decbfadd	Rapuncel credential-stealing payload
Domain	albinofennel[.]com	Primary payload server
Domain	hanselarinmusky[.]com	Secondary payload server
GitHub	github[.]com/LastPass-Authenticator	Fake LastPass Authenticator repository
GitHub Pages	lastpass-authenticator[.]github[.]io	Fake download portal
IP	2.26.126[.]50	Rapuncel data-exfiltration server
File Path	C:\Windows\System32\drivers\nvfsflt64.sys	Renamed malicious driver
Driver Service	NvFsFilter	Malicious driver service
Device Path	\\.\Alinubx	Malicious driver interface
File	ProtectR3.dll	Rootkit helper
File	vsdbg.dll	Malicious loader
File	browser_decryption.log	Credential-stealing artifact
Signing Metadata	Henan Dafeng Software Co., Ltd.	Related driver-signing identity

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Organizations should also monitor for renamed vsdbg.exe processes launching unusual child processes, kernel driver loads followed by mass termination of security tools, and large ZIP downloads from suspicious GitHub Pages lures.

Users who executed the fake installer should treat all credentials stored on the affected system as compromised. Change passwords, wallet credentials, browser sessions, and application tokens from a separate, known-clean device.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC

The post Hackers Use Microsoft-Signed Driver to Disable 145 Security Tools and Steal Passwords appeared first on Cyber Security News.