We’ve identified a huge social-engineering campaign designed to steer people into online gambling sites under the impression they’re installing a legitimate app.

We’re calling it FriendlyDealer. It’s been observed across at least 1,500 domains, each hosting a website that impersonates the Google Play or Apple App Store. Users think they’re downloading a gambling app from a trusted source, with all the checks, reviews, and safeguards that implies. But they’re actually still on a website, installing a web app that then redirects them to casino offers through affiliate links.

The campaign doesn’t steal passwords or install traditional malware. Instead, it makes money through commissions every time someone signs up or deposits money at one of these sites.

That might sound less serious than a banking Trojan, but the end result is people being funneled into unregulated gambling sites with no age verification, no deposit limits, and no consumer protections. And it comes at a time when gambling addiction is being called the fastest explosion of gambling the country has ever seen.

One kit, dozens of apps, built to mimic real app stores

FriendlyDealer is built as a single, reusable kit that can generate many different fake app listings.

The kit detects what device you’re using and shows you a different fake store accordingly. Android users see a fake Google Play Store. iPhone users see a fake Apple App Store. The kit even loads the correct system fonts for each platform (Google Sans on Android, San Francisco on iOS) so the typography matches what you’d expect on your own phone.

Under the hood, it’s a single web application that reads all of its content from one configuration file embedded in the page. Change that file, and you get a completely different app listing running on the same code.

The operators have used this to spin up at least twenty casino brands, from “Tower Rush” (189 deployments) to “Chicken Road” (97) to “BEAST GAMES: ICE FISHING” (43), which impersonates YouTube creator MrBeast. (It’s worth noting that some skins reuse the names of some legitimate gambling brands but none of these are affiliated with the operation.)

The reviews are fake. Different apps reuse identical usernames, profile photos, text, and developer replies, and they’re repeated across multiple brands. Before showing the fake store, the kit can also display a simple casino mini-game to build engagement.

The fake “Install” button on Android relies on a Chrome feature that only works on mobile. It captures Chrome’s install prompt and triggers it when tapped, so a real installation dialog appears. The usual warning about installing apps from unknown sources does not appear. Previous research has shown that apps installed this way can even display “Installed from Google Play Store” in your phone’s settings.

The code goes to extraordinary lengths to get you into the right browser. If you arrive through a Facebook or Instagram ad, you’re inside those apps’ built-in browser, which can’t trigger the install. On Android, the kit generates a special link that forces the page to reopen in Chrome. On iOS, it does the same thing but for Safari. If Chrome isn’t installed, the fallback sends you to the real Play Store to download it. There’s even a separate handler for Samsung’s browser. The browser-specific engineering is unusually detailed.

The page disables zooming, making close inspection harder. The kit assigns a per-user tracking ID and reuses it across analytics, event, push-registration, and offer-routing flows.

The kit is wired for paid advertising. The configuration includes empty slots for tracking pixels from four ad platforms: Google, Yandex, Facebook, and TikTok. The app and background script can forward Facebook-style ad identifiers (_fbc / _fbp) when those values are available. The code references Yandex telemetry fields and ships with Russian-language comments and debug strings, which is consistent with a Russian-speaking development context, though those artefacts could also have been inherited from a reused or purchased kit.

The flow is straightforward: buy ad traffic, detect the device, show a fake app store, trigger a real-looking install, and redirect to a casino through an affiliate link.

You’re not installing an app

When a user taps Install, the page doesn’t actually download an app. Instead, the browser creates what’s called a Progressive Web App (PWA). It’s essentially a website that behaves like an app, with its own icon on your home screen and its own splash screen. To most people it’s indistinguishable from a real app.

Once installed, the app can keep running in the background using browser features called service workers (keeping a persistent connection to your device). The samples include the main PWA worker and code to register a separate push worker (to send you notifications) when enabled.

The kit also knows when you’ve already installed it. It checks your device for its own PWA, and if it finds it, it skips the fake store entirely and sends you straight to the casino.

One domain ties it all together

Every FriendlyDealer deployment phones home to the same domain: ihavefriendseverywhere[.]xyz. This is the campaign’s data-collection server, and the name that inspired our tracking name for the operation.

The background script and app code send telemetry to this domain including browser language, timezone, user-agent data, optional user-agent client hints, campaign identifiers, and ad identifiers when those values are available. Much of this is sent via custom request headers.

Some requests use the HEAD method to stay lightweight.

The application code also sends something the background script doesn’t: JavaScript error reports. Every crash, every failed resource load, every unhandled exception that occurs on the victim’s device is caught, packaged into a structured error object with a timestamp and context, and posted to ihavefriendseverywhere[.]xyz/api/log_standard_err. In effect, the operators are collecting both user data and production error telemetry from real devices.

If a request fails (for example, due to poor signal), the background script stores it locally and retries later. Once the connection returns, the data is sent automatically.

The fake app also asks for notification permission. If the user grants it, the kit can register a push subscription and create a direct channel for future notifications. These appear like normal app notifications, giving the operators a direct line back to the user even after the app is closed.

Follow the money: affiliate commissions, not malware

FriendlyDealer doesn’t spread viruses or take over devices. The entire operation runs on affiliate commissions. Each fake app store page contains a hidden redirect to an affiliate tracking network. When a user signs up or deposits money, the operator gets paid.

We found multiple affiliate tracking networks in the code. A per-user ID appears across the kit’s analytics, event, push, and offer-routing logic, allowing activity to be correlated across multiple stages of the funnel.

This model explains the campaign’s enormous scale. Each domain is disposable. The kit is a template; change one configuration file and you have a new casino brand on a new domain in minutes. With gambling affiliate payouts reportedly ranging from $50 to $400 per depositing user, even a small conversion rate across a thousand domains adds up fast.

Who’s behind this?

We can’t attribute the campaign to a specific group, but there are clues. The source code contains Russian-language comments (for example, “Создаем таймер для измерения времени загрузки Vue “). One of the builds shipped with unstripped Russian debug strings that were scrubbed from the production version. The code integrates with Yandex Metrica, which is popular in Russia and the former Soviet states.

These point to a Russian-speaking development context, although the code could have been reused or purchased.

The code also contains affiliate marketing tags—preland-alias and preland-final-action—where a “pre-lander” is the page a visitor sees before the actual offer. The application code shows this tag controls the kit’s behavior: a value of 0 triggers a PWA install, while 1 redirects to an app store. Combined with plug-and-play ad pixel slots, per-deployment configuration, and staging/production logic, this strongly suggests a reusable kit built for multiple campaigns or operators, not a one-off project.

We found multiple builds of the same kit. The production version has debug messages removed, but other builds include full Russian-language error messages and support for Arabic numerals across the interface—download counts, ratings, review dates, and more. This does not look like a kit built for a single market; it appears designed to support regional variants at build time.

A familiar trick with a different payoff

Fake app store pages are a known technique, often used to steal banking credentials or deliver spyware. FriendlyDealer uses the same playbook, a convincing fake store and a real-looking install flow, but with a different goal. It doesn’t take over your phone or steal your passwords. It steers you toward gambling platforms and earns a commission when you spend money.

The harm is financial rather than technical: victims are funneled toward gambling offers through deceptive install and redirect flows, and may end up depositing money at sites they did not intentionally choose.

It’s also s a reminder that not every scam is after your passwords. Affiliate fraud, especially in online gambling, can fund enormous operations without ever touching a single credential. The people behind this built a factory: one template, twenty brands, more than 1,500 domains. Paid ads bring the traffic. The fake app stores seal the deal. The affiliate network pays the bills.

What makes this effective is that it abuses things that are supposed to be trustworthy. Chrome’s app installation flow on Android and Safari’s “Add to Home Screen” on iPhone are both legitimate features, doing what they were designed to do. The problem is that the page triggering the install is a lie. The kit is carefully engineered so only the right users, on the right devices, coming from the right ads, ever see it.

What to do if you installed one of these apps

On Android:

• Remove the app: Long-press the icon and tap Uninstall, or go to Settings > Apps and remove anything you don’t recognize.

• Clear the site data in Chrome: The app may leave data behind in your browser. Open Chrome > Settings > Site settings > All sites, find the site, and tap Clear & reset.

• Check notification permissions: Go to Chrome > Settings > Notifications and remove any sites you don’t recognize. Uninstalling the app does not remove notification access.

• Check other browsers: If you use Edge, Brave, or another Chromium-based browser, repeat the same steps there.

On iPhone:

• Remove the app: Long-press the app icon on your home screen and tap Remove App. On iOS, PWAs don’t install a background script the way they do on Android, so removing the icon also removes the cached site data.

• Clear the site data in Safari: Go to Settings > Safari > Advanced > Website Data, and search for the domain. Swipe to delete it. This clears any remaining cookies and stored data.

• Check notification permissions: Go to Settings > Apps > Safari. Scroll to the Settings for Websites section and tap Notifications. Find the site and remove or deny access.

If you deposited money after being routed through one of these pages and believe you were deceived, contact your bank or payment provider promptly.

Indicators of Compromise (IOCs)

Domains

   • ihavefriendseverywhere[.]xyz—Data exfiltration and error-logging server

   • valor[.]bet—Gate/checkpoint URL (/__pwa_gate path)

   • wikis[.]lifestyle—Hardcoded domain reference in application code

source

A new info-stealing malware named Infinity Stealer is targeting macOS systems with a Python payload packaged as an executable using the open-source Nuitka compiler.

The attack uses the ClickFix technique, presenting a fake CAPTCHA that mimics Cloudflare’s human verification check to trick users into executing malicious code.

Researchers at Malwarebytes say this is the first documented macOS campaign combining ClickFix delivery with a Python-based infostealer compiled using Nuitka.

Because Nuitka produces a native binary by compiling the Python script into C code, the resulting executable is more resistant to static analysis.

Compared to PyInstaller, which bundles Python with bytecode, it’s more evasive because it produces a real native binary with no obvious bytecode layer, making reverse engineering much harder.

“The final payload is written in Python and compiled with Nuitka, producing a native macOS binary. That makes it harder to analyze and detect than typical Python-based malware,” Malwarebystes says.

Attack chain

The attack begins with a ClickFix lure on the domain update-check[.]com, posing as a human verification step from Cloudflare and asking the user to complete the challenge by pasting a base64-obfuscated curl command into the macOS Terminal, bypassing OS-level defenses.


ClickFix step used in Infinity attacks | Source: Malwarebytes

The command decodes a Bash script that writes the stage-2 (Nuitka loader) to /tmp, then removes the quarantine flag, and executes it via ‘nohup.’ Finally, it passes the command-and-control (C2) and token via environment variables and then deletes itself and closes the Terminal window.

The Nuitka loader is an 8.6 MB Mach-O binary that contains a 35MB zstd-compressed archive, containing the stage-3 (UpdateHelper.bin), which is the Infinity Stealer malware.


The malware's disassembly view | Source: Malwarebytes

Before starting to collect sensitive data, the malware performs anti-analysis checks to determine whether it is running in a virtualized/sandboxed environment.

Malwarebytes’ analysis of the Python 3.11 payload uncovered that the info-stealer can take screenshots and harvest the following data:

   • Credentials from Chromium‑based browsers and Firefox

   • macOS Keychain entries

   • Cryptocurrency wallets

   • Plaintext secrets in developer files, such as .env

All stolen data is exfiltrated via HTTP POST requests to the C2, and a Telegram notification is sent to the threat actors upon completion of the operation.

Malwarebytes underlines that the appearance of malware like Infinity Stealer is proof that threats to macOS users are only getting more advanced and targeted.

Users should never paste into Terminal commands they find online and don’t fully understand.

source

Dell, HP, Lenovo (and other OEMs…)

Enterprise and consumer oriented PC and laptop vendors (including also Acer, ASUS, Dynabook, etc.) generally did better, but even they had:

   • staggered rollouts

   • inconsistent BIOS/UEFI update timing

   • some systems that required multiple reboots to apply DBX changes

As I looked at read forum posts at answers.microsoft.com, TenForums.com, ElevenForum.com, and TechPowerUp.com, I saw hundreds upon hundreds of forum threads that sought help in dealing with Secure Boot issues. Many involved laptops, and many more involved desktops, particularly DIY home-brew builds or those from boutique builders who assemble best-of-breed commercial parts to build bespoke PCs for well-heeled buyers (see next section).

Custom‑built PCs

Motherboards from the same vendor might behave differently depending on:

   • actual chipsets installed

   • firmware branch

   • release year

   • OEM vs retail SKU

Overall, the lack of standardization has been obvious. The Secure Boot problems users encountered have been all over the place. Some have ultimately yielded to Windows Update or manual changes. Others have stubbornly resisted all attempts at repair or correction. I’ve personally been all over this problem space, with failures recently overtaken by successes (but failures, nonetheless).

What users can do if Secure Boot updates fail


Checking the System Information (msinfo32) utility is the quickest way to verify if Windows recognizes your Secure Boot state as active.

There are all kinds of ways in which Secure Boot can fail. Windows update may report success, but the DBX (revocations list) never changes. Firmware may report that Secure Boot is “enabled,” but it isn’t being enforced (the PowerShell confirm-SecureBootUEFI will report false in that case).

Systems may boot but fail compliance checks (see Garlin Scripts section later in this story for more details). Bootloaders may not match DB entries, or systems may boot only reluctantly or not at all after updates (as happened on my ASRock B550 Extreme4 system). There’s a lot going on here, so there are lots of things to try should one need to fix them. Let’s march through a list of possibly poignant causes and related fixes.

Mismatched Keys (PK/KEK/DB/DBX)

If the PK or KEK is outdated, firmware may reject database updates into the list of valid credentials and values (DB) or its list of revoked items (DBX). If that happens, it’s worth trying one or all of these fixes:

• Reset to factory or default keys (usually available as a selectable action in UEFI, when Secure Boot is in Custom mode)

• Re-enroll Microsoft keys (usually requires re-applying a Microsoft update, which entails an uninstall/reinstall maneuver, possibly via DISM—WU offers time-limited rollback)

Firmware Ignores DB or DBX Updates

On some PCs and laptops, UEFI won’t apply DB or DBX updates except under certain conditions. Secure Boot may need to be disabled. The Compatibility Support Module (CSM, which enables “dual boot” into either BIOS or UEFI modes; modern PCs are UEFI-only, but older models often go both ways) must be turned off. Sometimes, Secure Boot keys must be cleared (another UEFI option) must be cleared before updates will take. Experimentation may be needed to see what’s what; if you’re lucky, you’ll find info from other intrepid explorers who’ve already seen and solved your particular problem.

Outdated Bootloaders

Older Windows install media or repair/recovery disks may incorporate bootloaders that are too old to work with Secure Boot. Indeed, this mismatch will accelerate later in 2026 after Microsoft gets more deeply into revoking CA-2011 (which is what most older bootloaders incorporate). If a bootloader is too old, DBX may block it. Fixes are fairly straightforward because bootloaders don’t interact with firmware (UEFI). Try any of the following repairs in this case:

• Run Windows Update: it may replace an outdated bootloader with a current one

• Rebuild boot files using the bcdboot utility

• Make sure the EFI partition is healthy (and rebuild it if it isn’t)

Firmware Bugs or Oddities

Especially on older PCs, it’s a good idea to update (flash) the UEFI before getting into Secure Boot. For old enough PCs, though, updates into 2023 and newer may simply not exist. But for systems that require multiple reboots, specific firmware versions, or manual Secure Boot database (DB, DBX) imports, a few techniques will be helpful:

• Update the firmware to the latest stable version (consider beta versions only if all other options have failed: you don’t want to trade one cause of instability for another)

• Wherever available, use vendor-supplied capsules or updates to apply Secure Boot database changes (e.g., my MSI MAG Tomahawk didn’t work properly until I’d flashed its UEFI, which included Secure Boot and CA-2023 elements built right in)

• Let Windows Update do its thing only AFTER the firmware is current: new updates and old firmware make for a volatile and issue-prone environment, as I learned on the ASRock B550 Extreme4 build

All in all, if users attempt Secure Boot compliance work from firmware updates to Windows updates, and only get into manual UEFI operations if necessary, they’re far less likely to get stuck in some pothole along that road.

How the scripts help solve Secure Boot update issues

Some of the most interesting developments during the CA-2023 rollout has been the emergence of community-driven tooling and diagnostics. In particular, Eleven Forum VIP and Guru user Garlin has provided a 50-page+ thread with useful PowerShell scripts, and backed them up with incredibly useful support and discussion. His scripts do the following:

   • enumerate Secure Boot keys

   • validate DB/DBX entries

   • detect mismatches

   • identify outdated bootloaders

   • verify enforcement status

   • generate detailed reports

For many users, Garlin’s scripts were the first clear window into what their firmware was actually doing. As an illustration of what the Garlin scripts illuminate, Figure 1 shows the output of his script named Check_UEFI-CA2023.ps1, captured from my recently rebuilt MSI MAG Tomahawk B550 desktop:


Output from Check_UEFI-CA2023.ps1 on the MSI MAG B550 desktop PC

Careful examination of the screenshot above shows the PC has both CA 2011 and CA 2023 Key Exchange Keys (KEKs) installed, with DB certs for UEFI CA 2011, Windows PCA 2011, and three flavors of CA 2023. The DBX certs list is empty (if you look below, you’ll see that CA 2011 hasn’t yet been revoked; once that happens, those entries should move here).

EFI files show that the boot manager allows UEFI CA 2023, as does the registry, and the latest Secure Boot code integrity policy is in place. MS uses this policy to block vulnerable or rollback-susceptible boot-critical binaries, particularly for Virtualization Based Security (VBS, as mentioned in the second item in the script’s overall output).

Finally, the script output shows the older CA-2011 certification hasn’t yet been revoked. That’s deliberate: I’m waiting to see how and when Microsoft will handle this through Windows Update, as they’ve promised to do sometime in the second half of 2026. We’ll see how that turns out…

Why these Scripts matter

Vendors rarely expose a PC’s full Secure Boot state. Windows surface only part of this picture. Firmware UIs are inconsistent and often call the same things by different names. Garlin’s scripts show us what’s going on inside the Secure Boot sphere, and tell us what actions might need to be taken to complete the overall process of updating and catching up.

What to do when Secure Boot won’t apply updates

Here’s a practical, step-by-step recovery workflow.

Step 1: Verify Current State

Use PowerShell or Garlin’s scripts to check:

   • PK

   • KEK

   • DB

   • DBX

   • Enforcement status

   • Bootloader versions

Step 2: Update Firmware

Install the latest BIOS/UEFI update.

Step 3: Reset Keys to Factory Defaults

Disable Secure Boot, set Mode to Custom, then reset or install factory default keys (different UEFIs use varying terminology). Whatever they call it, this often clears mismatches.

Step 4: Re-enable Secure Boot

Ensure CSM is disabled (it often gets turned on when UEFI gets updated; it must be turned off for Secure Boot to be enabled).

Step 5: Apply DBX Update(s)

Use Windows Update or vendor capsule(s), as available. Check the system (or motherboard) vendor’s support pages to look for UEFI and related updates. That’s what did the trick for my MSI MAG Tomahawk B550 motherboard.

Step 6: Rebuild Boot Files (if needed)

You can use built-in commands to recreate your boot files by running the bcdboot C:\Windows /f UEFI command. Sometimes, it may be necessary to boot to a repair or rescue disk and run this from the Windows Recovery (WinRE) environment. It is always safer to take this approach, and it will get you past boot problems or secure boot policy blocks if and when they should pop up.

Step 7: Re-verify State

Confirm DBX contains CA 2023 entries. Indeed, this would be a good time to run Garlin’s Check_UEFI-CA2023.ps1 script. (Note: if you look inside the file’s Properties window and check the Unblock option, you can run this script in PowerShell without changing or bypassing local execution policy. This is depicted in the screenshot below)

IMO, the Secure Boot Ecosystem needs reform

The gradual rollout of CA 2023 and recent efforts to catch systems up to current Secure Boot compliance have been interesting. But it has also exposed a wide range of systemic issues and problems. For one thing, firmware vendors lack consistent implementations and terminology, so it falls on IT pros and other installers to make things work. To exacerbate things, documentation is often poor, and fails to address remediations when things break or don’t work properly.

Right now, update pipelines are fragile. One misstep (such as failing to set Secure Boot to Custom mode before seeking to reinstall default keys) can cause the update process to get stuck, and can interfere with normal boot behaviors. On one of my ASRock desktops, I couldn’t restart that PC normally, and could only use a deep, cold boot to get into UEFI or run through the boot cycle (this lasted two weeks before I switched motherboards to get things working normally again). This also drives my observation that OEMs and motherboard vendors vary widely in quality of Secure Boot implementation and handling. At the same time that the ASRock mobo was driving me bonkers, I had no problems with any of my Lenovo systems (some dating back to 2018), nor my Dell mini-PC or an ASUS Snapdragon laptop, either.

What I learned during this process is that Secure Boot is only as strong as its weakest link. Some systems, alas, have weak links. Many of those weak links turn what should be a routine update into a struggle. Some of them can require even more drastic measures, like a system replacement or motherboard swap.

What Microsoft, OEMs, and users must do

All the kids on this playground need to do certain things to improve the current Secure Boot morass. In my opinion, here’s how this shakes out across Microsoft, OEMs and the user community. To begin with, Microsoft should enforce stricter certification, with improved diagnostics and better tools (Garlin’s scripts are pretty straightforward in hindsight; there’s no reason why MS can’t offer more polished implementations to help things along).

Next, the OEMs could do a lot to standardize firmware behavior and adopt consistent terminology. They can test their DB update more and more thoroughly, and provide more insight and clarity into Secure Boot state and values in their UEFI interfaces. A robust, automated rollback tool would also help undo incorrect or bad choices.

And finally, users should take security more seriously. This means updating firmware as new updates emerge, and resolving to use (not disable) Secure Boot except when installs, configuration changes, or updates demand it be turned off (temporarily). Users should also verify their Secure Boot databases periodically to make sure they’re current and correct, and make sure their EFI partitions are healthy and up-to-date.

If everybody does their part, Secure Boot can do its job of protecting systems from boot and root-level compromise and attack. That’s pretty important, so I think it’s worth doing.

Secure Boot still matters, but it needs work

Secure Boot remains an important defense mechanism in the Windows security model. But the CA 2023 saga shows that this ecosystem is fragile, inconsistent, and overdue for modernization. The good news is that the industry is learning. Firmware vendors are improving. Microsoft is tightening requirements. Community tools are filling gaps. But the lesson is clear: trust is no set-it-and-forget-it thing. Trust must be maintained, verified, and occasionally repaired. Secure Boot is no exception.

My closing advice is to watch the time ticking as you work to solve Secure Boot problems, should they present themselves. If a problem takes half a day to fix, that’s tolerable. Any longer than that, and it’s time to start thinking about alternatives, workarounds, and replacements. While you’re thinking, you can turn Secure Boot off: Windows still works without it. But you may, as I did, decide to replace balky, stuck hardware components rather than keep fighting, with no certain resolution in sight. It’s up to you! ■

source

Updated March 18: Following confirmation of an emergency, out-of-band, security update impacting Windows 11 versions 25H2, 24H2 and Windows 11 Enterprise LTSC 2024, this article has been updated with a statement by Microsoft in response to a request for clarification on the reasons for the update after the Patch Tuesday rollout which appeared to have already addressed the CVE-2026-25172, CVE-2026-25173 and CVE-2026-26111 Windows Routing and Remote Access Service vulnerabilities.

Patch Tuesday has been and gone, but the monthly security updates from Microsoft just keep on coming. The latest is an emergency, out-of-band, hotpatch for a subset of Windows 11 enterprise users that addresses a bunch of criticial security vulnerabilities impacting the Routing and Remote Access Service which could give attackers the ability to execute remote code and, potentially, take control of the impacted device. Here’s what we know about the Common Vulnerabilities and Exposures designated as CVE-2026-25172, CVE-2026-25173 and CVE-2026-26111, and the emergency update itself itself.

Microsoft Windows 11 Hotpatch Security Update—What The Enterprise Needs To Know

The latest out-of-band security update from Microsoft is, truth be told, something of an oddity. I say that as it is a fix for three critical vulnerabilities that had already been addressed by the March Patch Tuesday rollout.

The Microsoft security advisory stated: “This issue only applies to a limited set of scenarios involving Enterprise client devices running hotpatch updates and being used for remote server management." The three vulnerabilities all affect the Windows Routing and Remote Access Service management tool, and connecting to a malicious server could be all it takes to trigger the attack chain.

CVE-2026-25172, CVE-2026-25173 and CVE-2026-26111 are all remote code execution vulnerabilities, using access to a malicious server by way of the RRAS interface to start exploitation. The official description from the Microsoft Security Response Center is that of an “integer overflow or wraparound in Windows Routing and Remote Access Service (RRAS) allows an authorized attacker to execute code over a network”

In other words, and here’s the important bit, an attacker who is already authenticated on the domain could essentially trick a domain-joined user to send a request to the malicious server via the RRAS snap-in. Given that a patch had already been made available, you may be wondering why there’s a need for this emergency hotpatch. The answer lies with the fact that the Patch Tuesday fix requires a device reboot, and something running your critical applications or services isn’t open to rebooting on a whim, for obvious reasons.

Which is where the hotpatch system comes into play, as it doesn’t require the reboot. A hotpatch will download and install in the background, deployed within the in-memory code of already running processes.

Microsoft has also confirmed that it will enable hotpatch security updates by default, through the Windows Autopatch enterprise service, with the release of the Windows security update in May for those managing devices using Intune and the Graph API.

“This change in approach patches devices significantly faster since they aren’t waiting for that restart. To see how this is working in the real world, we asked four different companies with 30-70K devices about their gains in the number of days to security compliance. They all reported achieving 90% patch compliance in half the previous time, without making any policy changes,” Microsoft said. “Today, there are over 10 million production devices enrolled in hotpatch updates,” the Microsoft announcement continued, “showing the level of adoption and trust companies like yours have in this capability.” Microsoft also teased that additional IT controls will be released in April for organizations not yet ready for this change.

Microsoft Issues Statement Providing Clarification On Windows 11 Out-Of-Band Hotpatch Security Update

“This hotpatch update is offered only to hotpatch‑enabled devices. No action is required for devices that receive standard Windows updates,” Microsoft said. According to Bleeping Computer, Microsoft had “previously released hotfixes for these flaws,” but re-released them to "ensure comprehensive coverage across all affected scenarios." What those scenarios were, and why the emergency hotpatch update was necessary, isn’t immediately clear.

I reached out to Microsoft for clarification, and a spokesperson provided the following statement: “We identified that the Routing and Remote Access Service (RRAS) vulnerability could affect Enterprise devices deploying Windows hotpatch updates on Windows 11, versions 24H2 and 25H2. To address this scenario, we released an out-of-band hotpatch update (KB5084597) for hotpatch-enabled devices, allowing rapid installation without requiring a restart. Currently, there is no indication of exploitation, and we recommend customers follow the updated CVE guidance to remain protected.”

source

When's the right time to do it

Safe mode helps you see if a buggy app is causing your Android phone to crash, freeze, or slow down.

Here's how.



If your Android phone starts crashing, freezing, or acting strangely, it could be for several reasons, but one common culprit is third-party apps.

Any app installed from the Google Play Store can cause problems due to bugs, compatibility issues, or poorly optimized updates. Thankfully, Android has a troubleshooting tool called "safe mode" that can help you figure out if that's indeed the issue.

Safe mode temporarily disables all third-party apps and runs only the core Android system and preinstalled software. That creates a clean environment so you can see whether the problem is a third-party app or perhaps something deeper, such as your hardware.

How to boot your Android phone into safe mode

Most Android phones support safe mode, including Google Pixel phones, Samsung Galaxy phones, and many others. For this guide, I'm using a Pixel phone, but the process is very similar across Android devices.

1. Open the power menu

The first step is accessing the power menu on your Android phone. Press and hold the Power button and Volume Up button together for a few seconds. This opens the power menu with options like Power off and Restart.


Elyse Betters Picaro / ZDNET

2. Enter Safe mode

Once the power menu appears, press and hold the Power off option instead of tapping it. After a moment, your Android phone will display a prompt asking if you want to reboot into safe mode. Tap OK to confirm.

Your phone will restart automatically.


Elyse Betters Picaro / ZDNET

3. Confirm you're in safe mode

After the phone restarts, check the bottom corner of the screen. You should see a small "safe mode" label.

You may also notice some apps appear grayed out or missing. That is normal. Safe mode disables all third-party apps that you downloaded from the Play Store, leaving only the system apps that came with the device.

Note: Safe mode also enables Airplane mode on your device, but you can turn that off.


Elyse Betters Picaro / ZDNET

4. Use your phone like normal

At this point, use your phone normally for a few minutes or even hours. If the crashing, freezing, or slowdown has stopped, there is a strong possibility that one of your installed apps was causing the issue.


Elyse Betters Picaro / ZDNET

5. Exit safe mode

Before you can track down problematic apps, you need to exit safe mode.

Simply restart your phone by pressing and holding the Power and Volume Up buttons and then tapping Restart. On some Android devices, you can tap the safe mode label to restart your phone and exit safe mode.

Your phone should boot back with all your apps available again.


Elyse Betters Picaro / ZDNET

6. Find the buggy app

This can take a bit of time, but it is the most reliable way to identify what is causing problems on your phone.

Once you have exited safe mode, start uninstalling recently installed or recently updated apps one at a time. After removing each app, restart your phone and check whether the issue returns. You can also try using your apps before deleting them. If one behaves strangely or you need to force stop it, you've likely found the offender.

You can find recently updated apps in the Google Play Store.

Tap your profile, go to Manage apps and device > Manage, and select Recently updated to sort apps by their most recent updates. You can also open an app listing to review its latest changes under What's new.


Elyse Betters Picaro / ZDNET



Q: What exactly does safe mode do on Android?

Safe mode itself doesn't fix your Android phone's problems. It simply helps you diagnose them.

Safe mode disables all third-party apps so only Android system software and preinstalled apps run. This then lets you determine whether issues like freezing, crashing, or slow performance are caused by an app. If your phone works normally in safe mode, you can usually narrow the cause down to a third-party app that was recently installed or updated.

Q: What if my phone still has problems in safe mode?

If your phone still has problems while in safe mode, the cause may be a deeper software issue or even a hardware problem. In that case, you may need to check for system updates to install, reset your device, or even contact the manufacturer for extra support.

You can also try clearing your Android phone's cache as the next troubleshooting step.

Q: Will safe mode delete my apps or data?

Safe mode primarily prevents third-party apps from running, but it does not delete them from your phone. Google warns that safe mode does remove some home-screen widgets. So, if you use widgets, it recommends taking a screenshot to help you put them back.

Q: Why does my phone run faster in safe mode?

With third-party apps disabled, your phone has fewer background processes to manage. If performance improves significantly, one of those apps may be using too many resources or crashing in the background, and you may want to delete it.

source