The Windows 11 OOBE is made of spaghetti

Leave a comment

The OOBE protocol

The OOBE is a web application, ms-cxh:// protocol is a custom handler that defines a couple of shortcuts to various pages, seemingly, for internal use. The list of available protocol strings can be retrieved by scanning Windows binaries for the ms-cxh:// occurrences. Here, I’ve compiled a whole list of links that are related to the OOBE.

Out-of-Box Experience

FRX stands for «First Run eXperience
RDX stands for «Retail Demo eXperience

ms-cxh://FRX/AAD

ms-cxh://FRX/INCLUSIVE

ms-cxh://FRX/TEAMEDITION

ms-cxh://FRXRDXINCLUSIVE

Microsoft Azure

The AAD acronym is commonly used and refers to Azure Active Directory; SSPR stands for Self-Service Password Reset.

ms-cxh://AADPINRESETAUTH

ms-cxh://AADSSPRms-cxh://AADWEBAUTH

Modern settings

MOSET probably refers to «Modern settings;
MAM stands for «Mobile Application Management.
MSA stands for «Microsoft Account

ms-cxh://MOSET/AADLOCAL

ms-cxh://MOSET/CONNECTTOWORK

ms-cxh://mosetmamconnecttowork?mode=mdm&username=%s&servername=%s

ms-cxh://mosetmdmconnecttowork

ms-cxh://MOSETMSA

ms-cxh://MOSETMSALOCAL

Microsoft account

ms-cxh://MSACFLPINRESET

ms-cxh://MSACFLPINRESETSIGNIN

ms-cxh://MSACXSIGNINAUTHONLY

ms-cxh://MSACXSIGNINPINADD

ms-cxh://MSACXSIGNINPINRESET

ms-cxh://MSAPINENROLL

ms-cxh://MSAPINRESET

ms-cxh://MSARDX

ms-cxh://MSASSPR

Windows Hello for Microsoft Intune

NTH stands for iNTune Hello
NGC stands for Next Generation Credential
ENT stands for Enterprise
MDM stands for Mobile Device Management

ms-cxh://NTH

ms-cxh://NTH/AADRECOVERY

ms-cxh://NTHAADNGCFIXME

ms-cxh://NTHAADNGCONLY

ms-cxh://NTHAADNGCRESET

ms-cxh://NTHAADNGCRESETDESTRUCTIVE

ms-cxh://NTHAADNGCRESETNONDESTRUCTIVE

ms-cxh://NTHAADORMDM?ngc=enabled

ms-cxh://NTHENTNGCFIXME

ms-cxh://NTHENTNGCONLY

ms-cxh://NTHENTNGCRESET

ms-cxh://NTHENTNGCRESETDESTRUCTIVE

ms-cxh://NTHENTORMDM

ms-cxh://NTHENTORMDM?ngc=enabled

ms-cxh://NTHNGCUPSELL

ms-cxh://NTHPRIVACY

ms-cxh://RDXRACSKUINCLUSIVE

Second-chance OOBE

personalized-scoobe-test.png

The Second-chance OOBE appears after you have compleated the initial OOBE and what happens when a billion dollar company gets greedy? They want more Data! So here they beg you to sign up for their services at a low cost and “free” Besides that, here are some of the links for the 2nd chance OOBE.

  • ms-cxh://SCOOBE
  • ms-cxh://SCOOBE%ws
  • ms-cxh://SCOOBE/UPGRADE

Cloud settings

  • ms-cxh://SETADDLOCALONLY
  • ms-cxh://SETADDNEWUSER
  • ms-cxh://SETCHANGEPWD
  • ms-cxh://SETPHONEPAIRING
  • ms-cxh://SETPHONEPAIRING scenarioId=SwiftKeyCloudClipboard
  • ms-cxh://setsqsalocalonly

Miscellaneous

  • ms-cxh://TSET/ADDFAMILY
  • ms-cxh://WLT
  • ms-cxh://WLTUC

Bypassing Securly Using their own Website

Leave a comment

Content filtering solutions are widely deployed in schools and enterprises to enforce acceptable use policies. Securly, a popular Chromebook filtering platform, operates primarily through browser extensions that intercept and redirect web traffic based on domain and path logic.

While reviewing Securly’s client-side request handling, I identified a logic flaw that allows URL spoofing by abusing domain suffix checks, potentially allowing filtered destinations to be misclassified as trusted.

At a glance, the filtering logic attempts to:

  • Track blocked tabs
  • Intercept redirects to /blocked
  • Allow redirects from trusted hosts (including securly.com)
  • Restore previously blocked URLs under certain conditions

However, the decision to trust a domain is based on a string comparison rather than a strict hostname boundary check.

Relevant Logic (Excerpted)

checkDomain(o.url,"securly.com")

This check is later used in conditional logic that determines whether a tab should be restored or removed from the blocked state.

The Core Problem: Domain Suffix Trust

The vulnerability arises from a suffix-based trust model.

If domain validation logic checks whether a hostname ends with securly.com, then all of the following would pass:

  • securly.com
  • login.securly.com
  • securly.com.attacker-domain.tld
  • anythingsecurly.com

Unless the implementation enforces dot-boundary and public suffix rules, the browser extension may treat attacker-controlled domains as trusted infrastructure.

This can cause:

  • Blocked URLs to be restored
  • Redirect logic to be bypassed
  • Filter enforcement to fail silently

Why This Happens in Practice

This type of flaw is common in browser extensions because:

  • Developers rely on endsWith() or regex checks for performance
  • URL parsing is deceptively complex
  • Public suffix lists are often ignored
  • Redirect logic becomes difficult to reason about over time

In this case, logic meant to protect against redirect loops unintentionally creates a trust boundary collapse.