Canadian Sovereign Threat Exercise: Windows 11 (further options)

Scenario Overview

Microsoft 365-Integrated Workstation (Scenario 1): A Windows 11 Enterprise device fully integrated with Microsoft’s cloud ecosystem. The machine is joined to Microsoft Entra ID (formerly Azure AD) for identity and possibly enrolled in Microsoft Intune for device management. The user leverages Office 365 services extensively: their files reside in OneDrive and SharePoint Online, email is through Exchange Online (Outlook), and collaboration via Teams is assumed. They also use Adobe Acrobat with an Adobe cloud account for PDF services. The device’s telemetry settings are largely default – perhaps nominally curtailed via Group Policy or a tool like O&O ShutUp10++, but Windows still maintains some level of background diagnostic reporting. System updates are retrieved directly from Windows Update (Microsoft’s servers), and Office/Adobe apps update via their respective cloud services. BitLocker full-disk encryption is enabled; since the device is Entra ID-joined, the recovery key is automatically escrowed to Azure AD unless proactively disabled, meaning Microsoft holds a copy of the decryption keyblog.elcomsoft.com. All in all, in Scenario 1 the user’s identity, data, and device management are entwined with U.S.-based providers (Microsoft and Adobe). This provides convenience and seamless integration, but also means those providers have a trusted foothold in the environment.

Fully Sovereign Workstation (Scenario 2): A Windows 11 Enterprise device configured for data sovereignty on Canadian soil, minimizing reliance on foreign services. There is no Azure AD/AAD usage – instead, user authentication is through a local Keycloak Identity and Access Management system (e.g. the user logs into Windows via Keycloak or an on-prem AD federated with Keycloak), ensuring credentials and identity data stay internal. Cloud services are replaced with self-hosted equivalents: Seafile (hosted in a Canadian datacenter) provides file syncing in lieu of OneDrive/SharePoint, OnlyOffice (self-hosted) or similar enables web-based document editing internally, and Xodo or another PDF tool is used locally without any Adobe cloud connection. Email is handled by an on-prem mail server (e.g. a Linux-based Postfix/Dovecot with webmail) or via a client like Thunderbird, rather than Exchange Online. The device is managed using open-source, self-hosted tools: for example, Tactical RMM (remote monitoring & management) and Wazuh (security monitoring/EDR) are deployed on Canadian servers under the organization’s control. All Windows telemetry is disabled via group policies and firewall/DNS blocks – diagnostic data, Windows Error Reporting, Bing search integration, etc., are turned off, and known telemetry endpoints are blackholed. The workstation does not automatically reach out to Microsoft for updates; instead, updates are delivered manually or via an internal WSUS/update repository after being vetted. BitLocker disk encryption is used but recovery keys are stored only on local servers (e.g. in an on-prem Active Directory or Keycloak vault), never sent to Microsoft. In short, Scenario 2 retains the base OS (Windows) but wraps it in a bubble of sovereign infrastructure – Microsoft’s cloud is kept at arm’s length, and the device does not trust or rely on any U.S.-controlled cloud services for its regular operation.

Telemetry, Update Channels, and Vendor Control

Microsoft-Facing Telemetry & Cloud Services (Scenario 1): By default, a Windows 11 Enterprise machine in this scenario will communicate regularly with Microsoft and other third-party clouds. Unless aggressively curtailed, Windows telemetry sends diagnostic and usage data to Microsoft’s servers. This can include device hardware info, performance metrics, app usage data, reliability and crash reports, and more. Even if an admin uses Group Policy or tools like O&O ShutUp10 to reduce telemetry (for instance, setting it to “Security” level), the OS sometimes re-enables certain diagnostic components after updatesborncity.comborncity.com. Built-in features like Windows Error Reporting (WER) may upload crash dumps to Microsoft when applications crash. Many Windows components also reach out to cloud services by design – for example, Windows Search might query Bing, the Start Menu may fetch online content, and SmartScreen filters (and Windows Defender cloud protection) check URLs and file signatures against Microsoft’s cloud. In an Office 365-integrated setup, Office applications and services add another layer of telemetry. Office apps often send usage data and telemetry to Microsoft (unless an organization explicitly disables “connected experiences”). The user’s OneDrive client runs in the background, continuously syncing files to Microsoft’s cloud. Outlook is in constant contact with Exchange Online. If the user is logged into the Adobe Acrobat DC app with an Adobe ID, Acrobat may synchronize documents to Adobe’s Document Cloud and send Adobe usage analytics. Furthermore, because the device is Entra ID-joined and possibly Intune-managed, it maintains an Entra ID/Intune heartbeat: it will periodically check in with Intune’s cloud endpoint for policy updates or app deployments, and listen for push notifications (on Windows, Intune typically uses the Windows Notification Services for alerts to sync). Windows Update and Microsoft Store are another significant channel – the system frequently contacts Microsoft’s update servers to download OS patches, driver updates, and application updates (for any Store apps or Edge browser updates). All of these sanctioned communications mean the device has numerous background connections to vendor servers, any of which could serve as an access vector if leveraged maliciously by those vendors. In short, Microsoft (and Adobe) have ample “touchpoints” into the system: telemetry pipelines, cloud storage sync, update delivery, and device management channels are all potential conduits for data exfiltration or command execution in Scenario 1 if those vendors cooperated under legal pressure.

Key surfaces in Scenario 1 that are theoretically exploitable by Microsoft/Adobe or their partners (with lawful authority) include:

In summary, Scenario 1’s design means the vendor’s infrastructure has tentacles into the device for legitimate reasons (updates, sync, telemetry, management). Those same tentacles can be repurposed for covert access. The device frequently “calls home” to Microsoft and Adobe, providing an attacker with opportunities to piggyback on those connections or data stores.

Sovereign Controls (Scenario 2): In the sovereign configuration, the organization has deliberately shut off or internalized all those channels to block vendor access and eliminate quiet data leaks:

Putting it together, Scenario 2’s philosophy is “disable, replace, or closely monitor” any mechanism where the OS or apps would communicate with or receive code from an external vendor. The attack surface for vendor-assisted intrusion is dramatically reduced. Microsoft’s role is now mostly limited to being the OS provider – and Windows, while still ultimately Microsoft’s product, is being treated here as if it were an offline piece of software. The organization is asserting control over how that software behaves in the field, rather than deferring to cloud-based automation from Microsoft.

Summary of Vendor-Controlled Surfaces: The table below highlights key differences in control and telemetry between the Microsoft-integrated Scenario 1 and the sovereign Scenario 2:

Feasible Exfiltration Strategies Under Lawful Vendor Cooperation

Given the above surfaces, a red team (or state actor with legal authority) aiming to covertly extract sensitive data would have very different options in Scenario 1 vs Scenario 2. The goal of such an actor is to obtain specific files, communications, or intelligence from the target workstation without the user or organization detecting the breach, and ideally without deploying obvious “malware” that could be forensically found later. We examine potential strategies in each scenario:

Scenario 1 (Microsoft/Adobe-Integrated) – Potential Exfiltration Paths:

In practice, a real-world adversary operating under U.S. legal authority would likely choose the least noisy path: first grab everything from the cloud, since that’s easiest and stealthiest (the user’s OneDrive/Email likely contain the bulk of interesting data). If additional info on the endpoint is needed (say there are files the user never synced or an application database on the PC), the next step would be to use Intune or Defender to snatch those with minimal footprint. Direct exploitation (hacking the machine with malware) might be a last resort because it’s riskier to get caught and not necessary given the “insider” access the vendors provide. As noted by observers of the CLOUD Act, “Microsoft will listen to the U.S. government regardless of … other country’s laws”, and they can do so without the customer ever knowingcyberincontext.cacyberincontext.ca. Scenario 1 basically hands the keys to the kingdom to the cloud providers – and by extension to any government that can legally compel those providers.

Scenario 2 (Sovereign Setup) – Potential Exfiltration Paths:

In Scenario 2, the easy buttons are gone. There is no large cache of target data sitting in a U.S. company’s cloud, and no remote management portal accessible by a third-party where code can be pushed. A red team or state actor facing this setup has far fewer covert options:

In essence, Scenario 2 forces an attacker into the realm of active compromise with a high risk of detection. There’s no silent “API” to request data; no friendly cloud admin to insert code for you. The attacker would have to either break in or trick someone, both of which typically leave more traces. Microsoft’s influence is reduced to the operating system updates, and if those are controlled, Microsoft cannot easily introduce malware without it being caught. This is why from a sovereignty perspective, experts say the only way to truly avoid CLOUD Act exposure is to not use U.S.-based products or keep them completely offlinecyberincontext.cacyberincontext.ca. Here we still use Windows (a U.S. product), but with heavy restrictions; one could go even further and use a non-U.S. OS (Linux) to remove Microsoft entirely from the equation, but that’s beyond our two scenarios.

To summarize scenario 2’s situation: a “red team” with legal powers finds no convenient backdoor. They might consider a very targeted hacking operation (maybe using a Windows 0-day exploit delivered via a phishing email or USB drop). But that moves firmly into illegal hack territory rather than something enabled by legal compulsion, and it risks alerting the victim if anything goes wrong. It’s a last resort. The stark difference with scenario 1 is that here the adversary cannot achieve their objective simply by serving secret court orders to service providers – those providers either don’t have the data or don’t have the access.

Detection Vectors and SOC Visibility

From the perspective of the organization’s Security Operations Center (SOC) or IT security team, the two scenarios also offer very different chances to catch a breach in progress or to forensically find evidence after the fact. A key advantage of the sovereign approach is not just reducing attack surface, but also increasing the visibility of anything abnormal, whereas the integrated approach can allow a lot of activity to hide in plain sight.

In Scenario 1, many of the potential exfiltration actions would appear as normal or benign on the surface. If Microsoft pulls data from OneDrive or email, that happens entirely in the cloud – the endpoint sees nothing. The user’s PC isn’t doing anything differently, and the organization’s network monitoring will not catch an external party retrieving data from Microsoft’s datacenters. The SOC is blind to that; they would have to rely on Microsoft’s transparency reports or an unlikely heads-up, which typically come long after the fact if at all (and gag orders often prevent any notificationmicrosoft.commicrosoft.com). If Intune is used to run a script on the endpoint, from the device’s viewpoint it’s just the Intune Management Extension (which is a legitimate, constantly-running service) doing its job. Many SOC tools will whitelist Intune agents because they are known good. Unless the defenders have set up specific alerts like “alert if Intune runs a PowerShell containing certain keywords or if large network transfers occur from Intune processes,” they might not notice. The same goes for using Defender or updates: if Defender suddenly declares a file malicious, the SOC might even think “good, it caught something” rather than suspecting it was a trigger to steal that file. Network-wise, Scenario 1’s workstation has frequent connections to Microsoft cloud endpoints (OneDrive sync traffic, Outlook syncing email, Teams, etc.). This means even a somewhat larger data transfer to Microsoft could blend in. For example, OneDrive might already be uploading large files; an attacker adding one more file to upload wouldn’t be obvious. If an exfiltration script sends data to https://login.microsoftonline.com or some Azure Blob storage, many network monitoring systems would view that as normal Microsoft traffic (since blocking Microsoft domains is not feasible in this environment). Additionally, because IT management is outsourced in part to Microsoft’s cloud, the org’s administrators might not have logs of every action. Intune activities are logged in the Intune admin portal, but those logs could potentially be accessed or altered by Microsoft if they were carrying out a secret operation (at least, Microsoft as the service provider has the technical ability to manipulate back-end data). Moreover, the organization might not even be logging Intune actions to their SIEM, so a one-time script push might go unnoticed in their own audit trail.

It’s also worth considering that in Scenario 1, much of the security stack might itself be cloud-based and under vendor control. For example, if the organization uses Microsoft Defender for Endpoint (the cloud-managed EDR) instead of Wazuh, then Microsoft actually has direct insight into the endpoint security events and can even run remote response actions. (They said default Defender AV in this case, but many enterprises would have Defender for Endpoint, which allows remote shell access to PCs for incident response. A malicious insider at Microsoft with the right access could initiate a live response session to dump files or run commands, all under the guise of “security investigation.”) Even without that, default Defender AV communicates with Microsoft cloud for threat intelligence – something a sophisticated attacker could potentially leverage or at least use to their advantage to mask communications.

Overall, detection in Scenario 1 requires a very vigilant and somewhat paranoid SOC – one that assumes the trusted channels could betray them. Most organizations do not assume Intune or O365 will be turned against them by the service provider. Insider threat from the vendor is not typically modeled. Therefore, they may not be watching those channels closely. As a result, an exfiltration could succeed with low risk of immediate detection. Forensic detection after the fact is also hard – how do you distinguish a malicious Intune script from a legitimate one in logs, especially if it’s been removed? The endpoint might show evidence of file archives or PowerShell execution, which a skilled investigator could find if they suspect something. But if they have no reason to suspect, they might never look. And if Microsoft provided data directly from cloud, there’d be nothing on the endpoint to find at all.

In Scenario 2, the situation is reversed. The workstation is normally quiet on external networks; thus, any unusual outgoing connection or process is much more conspicuous. The SOC likely has extensive logging on the endpoint via Wazuh (which can collect Windows Event Logs, Sysmon data, etc.) and on network egress points. Since the design assumption is “we don’t trust external infrastructure,” the defenders are more likely to flag any contact with an external server that isn’t explicitly known. For instance, if somehow an update or process tried to reach out to a Microsoft cloud URL outside the scheduled update window, an alert might fire (either host-based or network-based). The absence of constant O365 traffic means the baseline is easier to define. They might even have host-based firewalls (like Windows Firewall with white-list rules or a third-party firewall agent) that outright block unexpected connections and log them.

If an attacker tried an Intune-like approach by compromising Tactical RMM, the defenders might notice strange behavior on the RMM server or an unplanned script in the RMM logs. Given the sensitivity, it’s likely the org closely monitors administrative actions on their servers. And any outsider trying to use those tools would have to get past authentication – not trivial if properly secured. Even a supply chain backdoor, if triggered, could be caught by behavior – e.g., if an OnlyOffice process suddenly tries to open a network connection to an uncommon host, the SOC might detect that via egress filtering.

Table: Detection and Visibility Comparison (illustrating how different exfil vectors might or might not be detected in each scenario):

To boil it down: Scenario 1 provides plentiful cover and plausible deniability for an attack, while Scenario 2 forces the attack into the light or into more aggressive tactics that are easier to catch. In Scenario 1, the SOC might not even have the tools to detect a malicious vendor action, because those actions exploit the very trust and access that the org granted. As one analogy, Scenario 1 is like having a security guard (Microsoft) who has a master key to your building – if that guard is coerced or turns, they can enter and leave without breaking any windows, and your alarms (which trust the guard) won’t sound. Scenario 2 is like having no master key held by outsiders – any entry has to break a lock or window, which is obviously more likely to set off alarms or be noticed.

Risks, Limitations, and Sovereignty Impacts

The two scenarios illustrate a classic trade-off between convenience and control (or sovereignty). Scenario 1, the Microsoft 365 route, offers seamless integration, high productivity, and less IT overhead – but at the cost of autonomy and potential security exposure. Scenario 2 sacrifices some of that convenience for the sake of data sovereignty, at the cost of more complexity and responsibility on the organization’s side. Let’s unpack the broader implications:

Scenario 1 (Integrated with U.S. Cloud Services): Here, the organization enjoys state-of-the-art cloud tools and probably lower IT burden (since Microsoft handles identity management infrastructure, update delivery, server maintenance for Exchange/SharePoint, etc.). Users likely have a smooth experience with their files and emails syncing across devices, rich collaboration features, and so on. However, the sovereignty risk is significant. As Microsoft’s own representative admitted in 2025, if the U.S. government comes knocking for data – even data stored in a foreign jurisdiction – Microsoft will hand it over, “regardless of [Canadian] or other country’s domestic laws.”cyberincontext.cacyberincontext.ca Data residency in Canada does not equal protection, because U.S. law (CLOUD Act) compels U.S. companies to complythinkon.com. This directly undermines the concept of “Canada’s right to control access to its digital information subject only to Canadian laws”cyberincontext.ca. In Scenario 1, Canadian law is effectively sidestepped; the control is ceded to U.S. law once data is in Microsoft’s cloud. For a public sector or sensitive organization, this means potentially breaching legal requirements (many Canadian government departments have policies against certain data leaving Canada – yet using O365 could violate the spirit of that if not the letter, due to Cloud Act). The national security implication is that foreign agencies might get intelligence on Canadian operations without Canadian oversight. The scenario text mentioned that even Department of National Defence (DND/CAF) uses “Defence 365” – a special Microsoft 365 instance – and that in theory none of that is immune to U.S. subpoenascyberincontext.ca. This is a glaring issue: it means a foreign power could access a nation’s defense data covertly. As a result, experts and officials have been raising alarms. For example, Canada’s own Treasury Board Secretariat acknowledged that using foreign-run clouds means “Canada cannot ensure full sovereignty over its data.”thinkon.com And commentators have said this “undermines our national security and exposes us to foreign interference”, calling for sovereign cloud solutionsthinkon.comthinkon.com. In everyday terms, Scenario 1 is high-risk if one’s threat model includes insider threat at the vendor or foreign government orders. From a red-team perspective, Scenario 1 is like an open barn door: multiple avenues exist to exfiltrate data with minimal chance of getting caught. The defending org in Scenario 1 might also have a false sense of security – because everything is “managed” by reputable companies, they might invest less in their own monitoring (assuming Microsoft will take care of security). That complacency can lead to blind spots, as we described in detection. Finally, there’s also a vendor lock-in and reliability concern: reliance on Microsoft/Adobe means if those services go down or if the relationship sours (imagine political sanctions or trade disputes), the organization could be cut off. The ThinkOn blog cited a warning that the U.S. could even direct cloud providers to cut off Canadian clients in extreme scenariosthinkon.com. That’s an extreme case, but not impossible if geopolitics worsened. Essentially, Scenario 1 trades some sovereignty for convenience, and that comes with latent risks that may not manifest until a crisis – at which point it’s too late to easily disentangle.

Scenario 2 (Fully Sovereign in Canada): This setup is aligned with the idea of a “Canadian Sovereign Cloud and Workplace”. The clear benefit is that it dramatically reduces the risk of unauthorized foreign access. If the U.S. wants data from this organization, it cannot get it behind the scenes; it would have to go through diplomatic/legal channels, which involve Canadian authorities. The organization would likely be aware and involved, allowing them to protect their interests (perhaps contesting the request or ensuring it’s scoped properly). This upholds the principle of data sovereignty – Canadian data subject to Canadian law first and foremost. Security-wise, Scenario 2 minimizes the attack surface from the supply-chain/insider perspective. There’s no easy vendor backdoor, so attacks have to be more direct, which are easier to guard against. The organization has complete control over patching, configurations, and data location, enabling them to apply very strict security policies (like network segmentation, custom hardening) without worrying about disrupting cloud connectivity. For example, they can disable all sorts of OS features that phone home, making the system cleaner and less porous. Visibility and auditability are superior: all logs (from OS, apps, servers) are owned by the org, which can feed them into Wazuh SIEM and analyze for anomalies. There’s no “shadow IT” in the form of unknown cloud processes. In terms of compliance, this scenario likely meets Canadian data residency requirements for even the highest protected levels (since data never leaves Canadian-controlled facilities).

However, Scenario 2 has trade-offs and limitations. Firstly, the organization needs the IT expertise and resources to run these services reliably and securely. Microsoft 365’s appeal is that Microsoft handles uptime, scaling, and security of the cloud services. In Scenario 2, if the Seafile server crashes or the mail server is slow, it’s the organization’s problem to fix. They need robust backups, disaster recovery plans, and possibly redundant infrastructure to match the reliability of Office 365. This can be costly. Secondly, security of the sovereign stack itself must be top-notch. Running your own mail server, file cloud, etc., introduces the possibility of misconfigurations or vulnerabilities that attackers (including foreign ones) can target. For example, if the admin forgets to patch the mail server, an external hacker might break in – a risk that would have been shouldered by Microsoft in the cloud model. That said, one might argue that at least if a breach happens, the org finds out (they see it directly, rather than a cloud breach that might be hidden). Another challenge is feature parity and user experience. Users might find OnlyOffice or Thunderbird not as slick or familiar as the latest Office 365 apps. Collaboration might be less efficient (though OnlyOffice and Seafile do allow web-based co-editing, it might not be as smooth as SharePoint/OneDrive with Office Online). Integration between services might require more effort (Keycloak can unify login, but not all apps might be as seamlessly connected as the Microsoft ecosystem). Training and change management are needed to ensure users adopt the new tools properly and don’t try to circumvent them (like using personal Dropbox or something, which would undermine the whole setup). Therefore, strong policies and user education are needed to truly reap the sovereignty benefits.

From a red team perspective focusing on lawful U.S. access, Scenario 2 is almost a dead-end – which is exactly the point. It “frustrates attempts at undetected exfiltration,” as we saw. This aligns with the stance of Canadian cyber officials who push for reducing reliance on foreign tech: “the only likely way to avoid the risk of U.S. legal requests superseding [our] law is not to use the products of U.S.-based organizations”cyberincontext.ca. Our sovereign scenario still uses Windows, which is U.S.-made, but it guts its cloud connectivity. Some might push even further (Linux OS, Canadian hardware if possible) for extreme cases, but even just isolating a mainstream OS is a huge improvement. The cost of silent compromise becomes much higher – likely high enough to deter all but the most resourceful adversaries, and even they run a good chance of being caught in the act. The broader impact is that Canada (or any country) can enforce its data privacy laws and maintain control, without an ally (or adversary) bypassing them. For example, Canadian law might say you need a warrant to search data – Scenario 2 ensures that practically, that’s true, because data can’t be fetched by a foreign court alone. Scenario 1 undermines that by allowing foreign warrants to silently reach in.

In conclusion, Scenario 1 is high-risk for sovereignty and covert data exposure, suitable perhaps for low sensitivity environments or those willing to trust U.S. providers, whereas Scenario 2 is a high-security, high-sovereignty configuration aimed at sensitive data protection, though with higher operational overhead. The trend by October 2025, especially in government and critical industries, is increasingly towards the latter for sensitive workloads, driven by the growing recognition of the CLOUD Act’s implicationsthinkon.comcyberincontext.ca. Canada has been exploring ways to build sovereign cloud services or require contractual assurances (like having data held by a Canadian subsidiary) – but as experts note, even those measures come down to “trusting” that the U.S. company will resist unwarranted orderscyberincontext.ca. Many are no longer comfortable with that trust. Scenario 2 embodies a zero-trust stance not only to hackers but also to vendors and external jurisdictions.

Both scenarios have the shared goal of protecting data, but their philosophies differ: Scenario 1 says “trust the big vendor to do it right (with some risk)”, Scenario 2 says “trust no one but ourselves”. For a red team simulating a state actor, the difference is night and day. In Scenario 1, the red team can operate like a lawful insider, leveraging vendor systems to achieve goals quietly. In Scenario 2, the red team is forced into the role of an external attacker, with all the challenges and chances of exposure that entails. This stark contrast is why the choice of IT architecture is not just an IT decision but a security and sovereignty decision.

Sources: This analysis drew on multiple sources, including Microsoft’s own statements on legal compliance (e.g., Microsoft’s admission that it must comply with U.S. CLOUD Act requests despite foreign lawscyberincontext.ca, and Microsoft’s transparency data on law enforcement demandsmicrosoft.commicrosoft.com), as well as commentary from Canadian government and industry experts on cloud sovereignty risksthinkon.comthinkon.com. Technical details on Intune’s capabilitieslearn.microsoft.com and real-world misuse by threat actorshalcyon.ai illustrate how remote management can be turned into an attack vector. The default escrow of BitLocker keys to Azure AD was noted in forensic analysis literatureblog.elcomsoft.com, reinforcing how vendor ecosystems hold keys to the kingdom. Additionally, examples of telemetry and update control issuesborncity.comborncity.com show that even attempting to disable communications can be challenging – hence the need for strong network enforcement in Scenario 2. All these pieces underpin the conclusion that a fully sovereign setup severely limits silent exfiltration pathways, whereas a cloud-integrated setup inherently creates them.