Thoughts on Technology and IT

Red Team Operational Plan: Covert Data Exfiltration from a Microsoft 365-Secured Workstation (chatGPT deep research)

1. Executive Summary

This report details a lawful, covert red team operation against a Windows 11 research workstation secured by Microsoft 365 services. With full Microsoft cooperation under the FISA/CLOUD Act, the red team’s objective is a one-time, non-persistent and undetected extraction of sensitive data. Target data includes all documents synced via SharePoint/OneDrive, the local document repository, and the user’s entire Outlook (Exchange Online) mailbox (emails and attachments). We outline access vectors enabled by Microsoft’s covert assistance, tactics for locating and collecting data via Defender telemetry and Microsoft Graph APIs, methods to quietly extract Outlook content, and strategies for exfiltrating SharePoint/OneDrive files. Crucially, we address evasion of Microsoft Defender for Endpoint (MDE) and SentinelOne EDR (with Intune management) throughout the operation. Each phase’s detection risks – from endpoint security alerts to Intune policy violations and SIEM correlation – are analyzed with realistic considerations for a Canadian public-sector SOC. We also present techniques for log evasion, cleanup, and maintaining no persistence on the endpoint. The plan includes specific tooling (both Microsoft-native utilities and open-source red team tools) relevant as of October 2025, and discusses data sovereignty trade-offs and visibility implications due to U.S. CLOUD Act involvementtheregister.com. By following this structured playbook, the red team can exfiltrate the target data undetected, leveraging insider cooperation from Microsoft while minimizing footprint and detection probability.

2. Objectives and Scope

Goal: Exfiltrate three categories of data from the target workstation in a single operation, without persistent implants or detection:

• Cloud-Synced Documents: All files synchronized to the device via OneDrive for Business and SharePoint (e.g. research data, reports, etc.).
• Local Documents: Any sensitive files stored locally on the workstation (outside of OneDrive sync folders).
• Outlook Mailbox: The entire contents of the user’s Exchange Online mailbox (emails and attachments), including any archives.

Scope & Constraints: The operation must remain stealthy and one-time. No enduring backdoors or long-term implants will be left on the device. All access will be ephemeral, with cleanup afterward. Microsoft’s secret cooperation allows use of privileged channels (Graph API, Intune, etc.) that would normally be unavailable, but the target organization (a Canadian public-sector entity) must remain unaware. The red team will simulate an external attacker leveraging this cooperation; thus all actions should appear as innocuous or normal as possible in logs. The engagement assumes the target user is not knowingly cooperating and that their device and accounts are fully patched and well-monitored. Any persistent changes, user-visible disruptions, or security alerts would jeopardize the operation’s secrecy and are to be avoided or immediately mitigated.

3. Target Environment Overview

The target is a Windows 11 research workstation hardened with Microsoft 365 security stack and endpoint protections:

• Azure AD Joined & Intune-Managed: The device is joined to Microsoft Entra ID (Azure AD) and managed via Intune, enforcing standard compliance policies (e.g. up-to-date OS, BitLocker enabled, antivirus active, etc.). Intune Conditional Access policies likely require the device to remain compliant (healthy) for continued access to M365 resources. Any tampering that marks the device non-compliant could cut off access or raise alerts.
• Endpoint Security – Defender & SentinelOne: The workstation runs Microsoft Defender for Endpoint (MDE) in EDR “block mode” alongside SentinelOne EDR in telemetry-only mode. In this configuration, SentinelOne serves as the primary AV/EDR for visibility, while MDE runs in passive mode but can autonomously block detected malicious behaviors that SentinelOne might misslearn.microsoft.com. (EDR block mode enables Defender to remediate post-breach artifacts even when another AV is primarylearn.microsoft.com.) SentinelOne in telemetry mode means it is not actively blocking threats, but it is capturing detailed behavior telemetry and potentially raising alerts for the SOC. Both tools feed data to the SOC’s monitoring systems, so stealth techniques must evade both detection engines.
• Productivity and Storage – M365 Integration: The user’s productivity data is tied into Microsoft 365 cloud services. Outlook is configured for Exchange Online (likely using Office 365 Outlook client with cached mailbox data). The user’s documents are stored in OneDrive for Business (personal OneDrive) and possibly SharePoint Online libraries (team sites) that are synced to the workstation via the OneDrive client. Thus, many files exist both on the local disk and in cloud storage. The device likely uses Known Folder Move redirecting Desktop/Documents to OneDrive, meaning “local” documents may also reside in cloud sync folders.
• Telemetry and Cloud Monitoring: The workstation continuously sends rich telemetry to Microsoft’s cloud security systems. Defender telemetry (device signals, alerts, file and process events) flows into Microsoft 365 Defender (and is accessible via Graph Security API and advanced hunting). Identity/sign-in events go to Microsoft Entra ID (Azure AD) logs (which include risk analytics via Identity Protection). The mention of “EntRAID” suggests that Microsoft Entra ID (Azure AD) is actively analyzing behavior and risk (e.g. impossible travel logins, atypical behavior patterns). The device’s compliance and sensor data may also feed into Microsoft Graph and potentially a centralized SIEM (like Microsoft Sentinel) aggregating signals. In short, the organization likely has unified visibility into endpoint, identity, and cloud-app telemetry. Our operation must navigate around these layers of detection.
• Security Operations Center (SOC): As a public-sector organization in Canada, the SOC likely follows Government security baseline practices. They may be using Microsoft Sentinel (or a similar SIEM) with out-of-the-box correlation rules and maybe some custom alerts. Many Canadian public-sector SOCs rely on Microsoft’s security suite for automated alerts; any overt malicious indicators in Defender, SentinelOne, Intune, or audit logs could be promptly flagged. However, if no obvious alerts fire, subtle anomalies might go unnoticed in the short term. The SOC will have audit logs available (Azure AD logs, O365 unified audit, Windows events) but may only review them in-depth during audits or after an alert. This shapes our stealth strategy: avoid triggering automated alerts in the first place.

Assumed Protections: No unmanaged channels are available (USB ports likely controlled, firewall on, etc.). Application control (WDAC or AppLocker) might be enforced for unauthorized executables – if so, running custom binaries could be blocked unless signed or masquerading as approved software. We assume typical Intune compliance settings (e.g. require AV enabled, no jailbroken status, device at or under a certain risk score). The operation will leverage only allowed/trusted processes where possible to blend in.

4. Assumed Cooperation and Legal Authority

Microsoft Cooperation: Under a FISA/CLOUD Act warrant, Microsoft is secretly assisting this operation. This cooperation grants the red team extraordinary access that normal attackers would not have, such as:

• Privileged cloud-side data access to the target’s M365 content. Microsoft can extract user data (emails, files) directly from their servers without the tenant’s knowledge, as legally compelled by the CLOUD Acttheregister.com. (Microsoft has admitted it must comply with such data requests, even for foreign-hosted datatheregister.com, while trying to do so as narrowly as possible.) This means we can retrieve cloud-stored content via service-level APIs or internal tools with minimal trace in tenant logs.
• Telemetry insights: The red team can access Microsoft’s internal telemetry or logs for this user/device (e.g. via Microsoft Graph or security APIs) to understand the target’s behavior and system state. Essentially, we have an over-the-shoulder view of what the SOC might see, enabling us to time actions or choose methods that blend into normal patterns. Microsoft might also share knowledge of detection rules or even temporarily suppress certain alerts for this operation.
• Trusted Execution Channels: The team can utilize Microsoft-managed channels on the endpoint. For instance, we can issue remote commands via Microsoft Defender for Endpoint’s live response shell or push a script via Intune. These methods leverage existing, trusted infrastructure (the Defender agent or Intune management agent), so activities may appear as routine IT or security tasks. Additionally, Microsoft’s cooperation could allow signing of any custom tools with a Microsoft certificate or adding them to allow-lists, making them effectively invisible to Defender/SmartScreen. (We will use such capabilities sparingly to avoid leaving obvious clues.)
• Identity/Token Access: If needed, Microsoft could grant access tokens or credentials for the target’s cloud identity or a service principal in the tenant with appropriate permissions. This avoids brute-force or exploits – we essentially impersonate an authorized context with Microsoft’s help. For example, Microsoft might secretly consent an Azure AD application with mailbox and file access, or add a hidden user to an eDiscovery role, purely for our use. These high-level accesses would normally generate audit entries, but Microsoft can ensure they happen out-of-band (e.g., using global admin rights not visible to the customer, or performing data pulls from the backend).

Operation Model: Despite this help, we structure the operation as if we are a stealthy external attacker – the cooperation is a means to quietly subvert defenses, not an excuse to be sloppy. We won’t simply ask Microsoft to hand over data (though they technically could), because we want to simulate techniques that could be used in a real red-team or intelligence scenario. Microsoft’s assistance will be used to bypass or quietly manipulate security controls (for instance, to obtain a foothold or to avoid detection), but the data collection will be performed in a manner resembling a covert attack to test the organization’s ability to notice.

Legal/Sovereignty Note: The reliance on CLOUD Act authority introduces data sovereignty trade-offs. The customer’s data, though stored in Canada, is being accessed under U.S. legal processtheregister.com. This means the organization has essentially no visibility or recourse – Microsoft is compelled to comply and cannot guarantee absolute data sovereignty to the clienttheregister.com. For our operation, this ensures secrecy (the tenant isn’t notified), but it also means any audit trails of these accesses are suppressed or kept within Microsoft. We will discuss the implications in a later section (Section 11). The team must be cautious that any direct actions on the tenant’s systems don’t inadvertently tip off the customer, as that would expose the legally covert operation.

5. Initial Access Vectors (with Microsoft Support)

To initiate our operation on the endpoint, we have several vector options, all made feasible by Microsoft’s cooperation. These grant us an initial execution capability on the target workstation without using malware exploits or phishing the user, thus minimizing risk of detection at the perimeter.

• Intune Deployment (Device Management Channel): Using Intune’s device management capability, we can remotely execute code or scripts on the workstation under the guise of a management action. Intune allows pushing of PowerShell scripts or Win32 apps to devices. With Microsoft’s help, we can create a hidden Intune policy or use a backend method to deploy our payload without the tenant admins’ knowledge. For example, a script could be assigned to only this device (scoped to a dummy group) to run a PowerShell command or memory-only dropper. The script would run as SYSTEM, giving us high privilege code execution. We must craft the script to look harmless or common (e.g. named similar to a Windows update script) to blend in. Detection considerations: Intune logs the initiation of scripts/apps (which tenant admins could see if they looked), but Microsoft could execute it outside the normal logging pipeline or at a time that avoids notice. We will remove any deployed package after execution. This method gives us direct control over the endpoint in a trusted way – the Intune management agent launching a script is normal, and any binary can be pre-approved or signed. We will use this to run our collection tasks if needed (especially to gather local files).
• Microsoft Defender for Endpoint (MDE) Live Response: As an alternative (or complement) to Intune, we can leverage MDE’s Live Response feature. With proper permissions, security operators can open a remote shell on the device via the Defender agentlearn.microsoft.comdocs.cybertriage.com. Microsoft can covertly initiate a Live Response session to the device, giving the red team an interactive shell (running as SYSTEM by default). Through this shell we can run built-in commands or scripts to carry out file searches, copying, or even execute binaries (with some limitations – MDE’s live response supports running pre-uploaded scripts or built-in tools, but not arbitrary .exe directly without a script wrapperreddit.com). This is extremely powerful because it uses the security agent’s trusted channel – from the network’s perspective, it’s just Defender traffic to Microsoft, and from the OS perspective, a sanctioned agent is doing work. We can use live response to directly collect files (Defender can even download files off the host to the portal) and to run collection scriptsreddit.comreddit.com. Detection considerations: A Live Response session might be visible to tenant admins in the Defender portal (as an action logged under the initiating username). However, Microsoft could use a hidden or system account to avoid attribution, or simply assume the organization is unlikely to notice a single remote session among normal operations. We will prefer using live response for stealthy data collection if possible, since it leaves minimal trace on the endpoint (no new processes aside from the already-running agent).
• Azure AD Identity Impersonation: With Microsoft’s assistance, we could impersonate the user’s identity tokens for cloud access. For instance, Microsoft could generate an OAuth token for Graph API with the user’s permissions (or greater) without the user’s involvement. This would let us access their cloud data (emails, files) directly through Graph API calls as if we were the user or a privileged app. This vector doesn’t immediately give OS-level access, but it might negate the need to ever execute code on the endpoint for cloud data. We will indeed use Graph API extensively for grabbing mailbox and OneDrive data (discussed in Section 6 and 7). The initial “access” here is essentially cloud-side rather than endpoint: we leverage an application-level backdoor – a registered Azure AD application or a direct Graph service call – that Microsoft pre-authorizes to read the target’s data. This approach is invisible to the user and can be configured not to appear in the tenant’s app consent logs (Microsoft can do a direct service-to-service call under legal authority). We won’t need any malware on the endpoint for extracting cloud content if this route suffices. Detection considerations: Standard Azure AD logging might record a Graph API login or data access by a service principal. However, because this is done under legal covert access, Microsoft likely ensures it doesn’t trigger tenant alerts. Notably, the new Graph Mailbox Export endpoints do not generate audit events by design (currently)office365itpros.com, which works to our advantage for stealth cloud exfiltration.
• Software Update/Supply Chain Vector: In extreme cases, Microsoft could push a manipulated software update to just this device (for example, via Windows Update or Office Update channels) that contains a payload. Given the surgical options above, this blunt approach is not necessary, but it’s worth noting as a capability. A malicious update (e.g., a special Windows Defender signature update that runs a particular command or an Office add-in update) could execute code under Microsoft’s own signature. This would be nearly impossible for the endpoint to flag as malicious since it’s coming from a trusted source. We will not rely on this except as a contingency, because it’s heavy-handed and could have side effects.

Initial Access Plan: We will likely use a combination of Graph API impersonation (for direct cloud data access) and MDE Live Response or Intune script (for on-box actions). For example, cloud data (mail, OneDrive files) can be pulled via Graph without touching the endpoint. For any files exclusively on the local disk, we can jump in via Defender Live Response to search and collect them. By avoiding any traditional “exploits” or phishing, we eliminate perimeter detection – no suspicious emails, no malware downloads from unknown servers, and no exploit kit traffic will occur. The entry is through management and security channels that are expected in a healthy environment.

Timing will be carefully chosen. Using telemetry, we’ll identify when the user is inactive (e.g., late night or a weekend). With Microsoft’s help, we can confirm the user’s typical working hours or even see if the machine is powered on and idle. The initial actions (script execution or live session) will be done when interactive use is low, to reduce the chance the user notices a brief command prompt window or performance spike.

6. Reconnaissance and Content Discovery

Before and immediately after initial access, the red team will perform reconnaissance to locate the target data and prepare for extraction. Thanks to Microsoft’s telemetry and Graph data, much of this recon can be done quietly from the cloud side, limiting on-box activity.

6.1 Defender Telemetry & Behavioral Patterning:
Using Microsoft 365 Defender’s data (available via advanced hunting or internal telemetry), we can search for clues about where relevant files are stored and how the user uses their system:

• File Activity Logs: The DeviceFileEvents table in Defender contains records of file creation, modification, and access on the endpointlearn.microsoft.com. We can query this (via Graph Security API or Defender portal) for recent activity by the user – e.g., which documents were opened or edited in the last 30 days. This can identify file paths of interest (e.g., if the user opened C:\Users\Alice\Documents\Research\projectX\design.docx, we know that directory likely holds important files). We’ll search for common document extensions (.docx, .xlsx, .pdf, .pptx, etc.) and large files. This telemetry-driven approach lets us map out the target’s “file landscape” without running a full disk scan ourselves. Note: DeviceFileEvents will only show files that had some event (open, modify, etc.) during the retention period; very old or untouched files might not appear. Still, it provides a focused starting point.
• Defender Alerts/Indicators: We will check if any security alerts have fired for file names or tools on the device (to avoid stepping on known tripwires). For instance, if Defender previously detected a hacking tool or suspicious script on this machine, we’d know to steer clear of anything similar in our approach. In our scenario, presumably the device is clean (no prior compromises), so no active alerts should exist.
• User Behavior (Entra ID and Graph): Microsoft Entra ID (Azure AD) identity logs and Microsoft Graph “Workplace Analytics” can reveal patterns like when the user is typically active, and which files or SharePoint sites they frequently use. If available, we can leverage Graph Insights API (which powers Delve/Office Graph) to see “trending” or “used” documents for the user. This might highlight important SharePoint files or collaborations. Additionally, Azure AD sign-in logs show from where and when the user logs in – ensuring our actions align with times the user is not expected (to avoid generating a “impossible travel” or atypical login alert). For example, if the user normally is in Toronto and logs in 9am-5pm, we do our work at 3am local time and route any cloud API calls through Canadian datacenters if possible, to avoid geo anomalies.
• EntRA ID Risk Reports: If available, we will review Identity Protection risk reports for this user (with MS help). This reveals if the account has any pre-existing risk (e.g., leaked credentials or unusual sign-in flags). We want a low profile – if the account was already flagged “risky”, an operation might trigger protective actions like MFA or password reset. Assuming a normal state, our careful approach (especially using Microsoft-internal channels) should not trigger these systems. Microsoft’s cooperation likely ensures that any identity risk analytics will ignore our service-level access, or at least not raise a user-facing challenge.

6.2 Graph API Recon (Cloud Content):
We will leverage Graph API calls (using the privileged token/app from initial access) to enumerate the user’s cloud content:

• OneDrive Enumeration: Using Microsoft Graph, we can list the root of the user’s OneDrive and all files/folders within. The endpoint is GET /users/{userid}/drive/root/children and subsequent calls for subfolders. This will give a full listing of filenames, sizes, and last modified dates. We can quickly identify large or likely sensitive files (by name or size) and decide if everything needs exfiltration or only specific folders. Because we want “all synced documents,” we’ll plan to retrieve everything in OneDrive anyway, but enumeration helps estimate volume and identify any very large data that might need special handling (like a large PST file or database dump). Graph can also reveal if the user has access to SharePoint document libraries (via List shared drives or listing followedSites). If, for example, the user is in a team SharePoint site (which often is the case for research projects), those files might be syncing to a folder on the device. We’ll confirm via Graph and include those in scope.
• Mailbox Recon: With the Graph Mail API, we can do a quick check of mailbox size and item count. For instance, using the Outlook REST API (/me/mailFolders) we can see how many emails are in the mailbox and if there’s an online archive. Since our plan is likely to use the new mailbox export API, we may not need to enumerate every folder first, but a quick peek at mailbox metadata ensures we know if it’s huge (e.g., tens of GB) – in which case we prepare for a large data transfer. We also might search for particular high-value items (e.g., any emails with certain keywords or attachments of certain types) if we needed to prioritize, but since objective is “all mailbox contents,” we’ll go for a full export.
• SharePoint Sites/OneDrive Content via Intune: Separately, Intune’s device records might list which SharePoint sites are synced on the device (the OneDrive Sync client can register in telemetry which libraries are syncing). If accessible, we’ll use that to double-check we don’t miss, say, a departmental SharePoint drive the user synced.

6.3 On-Device Reconnaissance:
After establishing initial access (e.g., getting a live response shell), we will perform some on-device discovery, carefully:

• File System Scan (targeted): Instead of indiscriminately scanning the entire disk (which could be time-consuming and potentially noisy), we’ll focus on known relevant directories. Likely directories include:
  
  • User Profile: C:\Users\<Username>\ – including Documents, Desktop, Downloads, etc. We expect Documents and Desktop to be either redirected to OneDrive or at least partly synced. We will verify this by checking for the presence of the OneDrive folder (usually C:\Users\<User>\OneDrive - <OrgName>\ for business accounts) and see if Documents is a junction pointing there. If not all files are synced, we will include local Documents in our search.
  • OneDrive Cache: The local OneDrive synced folder contains the actual files. If Files On-Demand is enabled, not all files have content locally until opened. We can force a download of all files by toggling them “Always keep on this device” (possibly via a command-line or by script using OneDrive’s client COM interface). But doing so might create network traffic and local CPU load; an alternative is to just download via Graph from cloud. We will weigh this; likely we opt for direct cloud download to avoid making the device do heavy lifting. Still, we enumerate the local OneDrive folder to identify which files are already present offline (the attrib command can show which files are available versus online-only).
  • Other Drives/Locations: If the workstation has secondary drives or special research directories (like D:\Data etc.), Intune inventory or prior telemetry might reveal them. We will list drives and any mounted network shares. Being a research PC, there could be specialized data directories. We must not forget things like browser downloads or email PSTs stored locally. We’ll search the usual suspects: user’s Download folder (there might be files saved that never got moved), any obvious project folder paths gleaned from telemetry.
• Credential & Access Recon: Although not our primary objective, we remain aware of any credentials on the box that could facilitate deeper access (e.g., saved service account passwords, Azure AD tokens, etc.). With MS cooperation, we likely don’t need to steal any credentials (we already have what we need), and doing so would risk detection (for example, dumping LSASS memory would trip MDE instantly). We explicitly avoid heavy actions like credential dumping or lateral movement – our focus is data on this device and associated cloud account only.
• Process/Memory Recon: We will briefly check if any process could interfere or tip off the user during exfiltration. For example, if some DLP agent or backup agent is running that might react to mass file copy, we want to know. With SentinelOne present, there might also be a local console or balloon alerts (though in telemetry mode, likely not). If any such processes exist, we might consider stopping them temporarily. However, stopping a security process is highly risky for detection, so our preference is not to kill any but to work around them. Knowing they exist is enough to plan evasion (addressed in Section 8).
• Stealth Checks: We’ll verify our presence is not noticed: e.g., ensure any command windows we spawned are hidden (when running via Intune or live response, this is usually headless anyway). If we deployed a script, we’ll confirm it self-deleted if that was part of design. Essentially, before moving to collection, the recon phase confirms we have the map of where data is and that the coast is clear to proceed.

By combining cloud-side reconnaissance (Graph and telemetry) with minimal on-device checks, we get a comprehensive picture of the target data locations. At this point, we should have:

• A list of OneDrive/SharePoint file paths to fetch (or confirmation we’ll fetch all).
• Confirmation of any unsynced local directories to collect.
• The size of the mailbox and plan to export it.
• The timing and method (which channel) for extraction that seems least risky.

Next, we move into the collection phase for each data category, using tailored methods to remain covert.

7. Collection Phase – Outlook Mailbox

Objective: Extract the entire mailbox (email and attachments) of the user without triggering M365 security alerts or audit logs that the customer SOC would see. We also want to avoid leaving any trace on the endpoint (e.g., we will not forward emails or sync to a mail client on the PC, which could be noticed).

Preferred Method: Microsoft Graph Mailbox Export (Cloud-Side):
We will utilize the Microsoft Graph Mailbox Export API (in beta as of 2025) to export mailbox contents. This API allows a full-fidelity export of mailbox items as an opaque data stream or PST filelearn.microsoft.comlearn.microsoft.com. Crucially, current findings show that using this Graph export does not generate any audit events in Exchange Onlineoffice365itpros.com. That means we can export the mailbox “without a trace” in the tenant’s audit logs – a glaring oversight but beneficial for our covert needsoffice365itpros.com.

Steps to do this:

1. Using our Graph API access (granted via cooperation – likely an application with MailboxExport permission or using Microsoft’s internal context), call the export endpoint for the user’s mailbox. This will package the entire mailbox (or we can do folder by folder) into a downloadable file. The API provides a way to download the content as an encrypted PST or binary blob.

2. Download the exported data stream to a secure location (e.g., an Azure storage controlled by Microsoft or directly to our system). Because this is done service-to-service, the traffic does not touch the user’s network or device at all – it goes from Exchange Online to us.

3. The result can be converted to a PST file if needed for analysis, but that is outside the target environment and thus safe from detection.

Evasion Considerations: Since this is done entirely in the cloud, the user’s endpoint and network are not involved – no chance for endpoint tools to see malicious activity. Azure AD might log that some service accessed mailbox items. But because the Mailbox Export API is meant for compliance and Microsoft is cooperating, such access is likely either suppressed or indistinguishable from Microsoft’s own background processes. Additionally, Exchange’s own auditing normally logs mailbox accesses by non-owner or by admin role. However, in our scenario, we expect Microsoft to either perform the export in a way that bypasses those logs or use an account that is excluded from audit (e.g., the service account performing eDiscovery under FISA might be exempt from tenant audit visibility). According to reporting, Microsoft acknowledged the lack of auditing on this API and will likely fix it, but as of Oct 2025 it’s still a gapoffice365itpros.com. We will exploit that gap fully.

Alternative Method: Legacy eDiscovery or EWS (Not Primary):
For completeness, if the Graph export API was unavailable, we had fallback options:

• Use Compliance eDiscovery: As a global admin (with MS support, we could be given eDiscovery Manager role in secret), search the mailbox and export to PST via Compliance Center. This usually does leave some traces (e.g., eDiscovery case creation might be logged, and the target organization’s compliance admin could potentially see a new case if they looked). It’s also slower and requires splitting PST if large. We prefer the Graph export to remain hidden.
• Use Exchange Web Services (EWS) or MAPI: In the past, attackers have used EWS to stealthily exfiltrate mail (notably the 2024 “Midnight Blizzard” nation-state attack abused stolen refresh tokens to call EWS and dump executive mailboxesoffice365itpros.com). EWS can fetch mail item by item. However, Microsoft is deprecating EWS (to be fully phased out by Oct 2026)office365itpros.com and Graph is the replacement. Also, abnormal EWS usage can be detected by Defender for Cloud Apps or unusual client profiles. The Graph Export API is newer and ironically more stealthy currently. So we will not use EWS unless absolutely necessary.

On-Endpoint Methods (Avoided): We explicitly choose not to extract mail via the endpoint (like configuring Outlook to dump a PST, or grabbing the OST file) because:

• Forcing Outlook to export a PST via a script (using Outlook COM automation) could display the Outlook application or slow the system, potentially alerting the user if they’re present. It also writes a big PST to disk, which might trigger file monitoring or consume noticeable disk space.
• Stealing the OST file: The local offline cache (.ost) is typically encrypted and tied to the profile – converting it to usable data is non-trivial without the account’s credentials. We’d rather get data directly from the source (Exchange Online).
• Using MAPI via PowerShell (e.g., New-MailboxExportRequest in Exchange Online PowerShell) also ultimately does a server-side export similar to eDiscovery, but again the audit/log issue arises.

Thus, Graph Mailbox Export is our primary tool: it’s cloud-to-cloud, fast, full-fidelity, and stealthy. According to Tony Redmond, attackers value any method that can exfiltrate mail without detection, making this API a prime candidateoffice365itpros.com.

Tooling: We will utilize either the Graph Explorer or a custom script with the Graph SDK to perform the export. Since this is a one-time operation, a simple approach is fine: for example, a PowerShell script using Invoke-MgGraphRequest to call the export and download. Microsoft likely provides us the necessary permissions via an app registration or using their backend access. No open-source tool is needed here, though it’s worth noting an admin with sufficient rights could script this with the Graph PowerShell module (some guides already show how to backup a mailbox via Graph API and save to PSTourcloudnetwork.com). Our “tool” is essentially the Graph API itself.

Post-extraction: Once we have the mailbox data off-site, we ensure the operation didn’t mark emails as “Read” or do anything user-facing. The Graph export is read-only and should be invisible to the mailbox user. We also aren’t deleting anything, just copying, so there’s no integrity impact on the mailbox. This aligns with our non-persistence rule – we leave everything as we found, just with a copy siphoned out. If by chance an audit record is generated (e.g., something in the Unified Audit Log after the fact), we may rely on Microsoft to purge or seal those under the national security context. But per current documentation, this export API isn’t auditedoffice365itpros.com, so likely nothing appears in the log that the customer’s SOC can access.

In summary, the entire Outlook mailbox will be exfiltrated directly from Exchange Online using a covert Graph API call. This phase should complete without touching the endpoint or alerting the user or admins, giving us a complete dump of email communications.

8. Collection Phase – SharePoint/OneDrive Documents

Objective: Gather all documents accessible to the user via OneDrive for Business and any synced SharePoint libraries. This includes files the user has in their OneDrive (personal storage) and files from team SharePoint sites that are synced to their device.

We approach this on two fronts: cloud-side extraction via Graph (to cover everything, especially if some files aren’t stored locally due to on-demand sync) and endpoint extraction (to grab anything already on disk or easier accessed via the device).

8.1 Cloud-Side File Exfiltration (Graph API & SharePoint):
Leveraging Graph API with high privileges, we can directly pull files from OneDrive/SharePoint:

• OneDrive via Graph: Using endpoints like /users/{user-id}/drive/root we can enumerate and download every file. Graph allows downloading a file’s content with an HTTP GET on the file’s @microsoft.graph.downloadUrllearn.microsoft.com. We will script this to iterate through all items. Given cooperation, we likely have permission such as Sites.Read.All or even Sites.FullControl.All on the tenant (granted via a stealth app or backend) which allows reading any SharePoint content. Specifically for the user’s OneDrive (which is a SharePoint site under the hood), we will ensure our account is a site collection admin or has the needed scope. If not initially, Microsoft can add our context as an admin to that OneDrive silentlyreddit.com. (Global admins by default don’t have OneDrive file access due to zero standing access model, but they can grant themselves itreddit.comreddit.com. Here, Microsoft can do it out-of-band so the customer admin isn’t alerted by any UI.)

We will download files in a structured way (possibly folder by folder to maintain some organization). Graph doesn’t offer a bulk zip download of a whole drive via a single call except through the UI, but we can automate multiple calls. If the dataset is huge, we could consider using OneDrive’s built-in export (which can produce a zip for selected files via the web UI) – but orchestrating that via API is complexlearn.microsoft.com. Instead, a straightforward iterative download is fine. Each file download is over HTTPS from SharePoint’s CDN endpoints, which should be fast within Microsoft’s network.

Stealth: These downloads via Graph will register as API calls by our app or account. To the target org’s perspective, it might look like the user (or an app) is accessing a lot of files. If these calls come from an IP not normally associated with the user, Defender for Cloud Apps (MCAS) might normally flag “mass download of files by unusual location.” However, because Microsoft is helping, we will route these calls either from an IP within the organization’s expected range or tag them in a way that MCAS ignores. Microsoft could e.g. perform the download on the backend or from an Azure IP in Canada to blend in. Also, if using an app ID, we can mark it as a first-party or compliant app so it doesn’t trigger suspicious OAuth app alerts. In essence, we assume these Graph interactions can be made opaque to the customer’s monitoring. If that were not certain, an alternative is to pull files via the device (discussed next) which would look like the user doing it on their machine, a normal activity.
* SharePoint Team Sites: If the user has access to SharePoint document libraries (common in research groups), there are two scenarios:
1. Synced to OneDrive client: Many users sync specific SharePoint folders to their workstation. If so, those files appear under a path like C:\Users\<User>\<OrgName>\\Site - Documents. We will identify these either via Graph or checking the OneDrive sync client status. If synced, we treat them like OneDrive and can get them from local or cloud.

1. Not synced: The user could access some SharePoint files via browser only (not stored locally). Those would not be on the PC. We’d then rely on Graph to fetch them directly (since our app permission likely can read any site content). We can enumerate sites the user is a member of (/users/{id}/followedSites or check groups/teams they are in) and then list files on those sites via Graph (/sites/{site-id}/drives). We will download any significant files from those as well. This ensures comprehensive coverage beyond just what’s synced.

We should be careful to respect any Data Loss Prevention (DLP) policies if present. For example, if the organization has DLP rules on SharePoint that trigger alerts on mass downloads or on copying files with sensitive info, doing it via Graph might bypass some of those (since it’s an admin/API action rather than a user action). But if not, we have Microsoft’s support to quietly bypass DLP enforcement.

8.2 Endpoint-Assisted Collection (Local Sync):
In parallel, we use the endpoint to grab any files present locally, especially if some might not be in the cloud:

• Using the live response shell or deployed script, navigate the user’s OneDrive folder and local document folders. We can use simple commands like dir /s or PowerShell Get-ChildItem to list all files and then copy them.
• If OneDrive files are on-demand (i.e., not fully downloaded), we have a choice: either trigger a download of them to local and then copy, or skip local and rely on cloud. Given Graph can get them, we might not need to force download on the endpoint at all. However, one trick: if network egress monitoring is stricter than Microsoft’s internal cloud copying, it might ironically be stealthier to have the OneDrive client sync them down (which is normal traffic to SharePoint), then grab them from disk, rather than using an external tool to download. But since our Graph method essentially mimics SharePoint’s own calls, it should be fine.
• For safety, we could initiate a “OneDrive sync refresh” via the endpoint – ensuring any file not yet synced down gets pulled. This can be done by programmatically iterating through the OneDrive folders (opening each file handle briefly, for instance). But doing this could create a flurry of disk and network activity on the endpoint that SentinelOne/Defender might notice (or at least log). Because we have direct cloud access, we likely don’t need to do this; we can just fetch missing files from cloud directly.
• Local Only Files: Our recon might find some files that are not in OneDrive at all (e.g., maybe something in C:\Research\ or a TrueCrypt container file etc.). For those, the endpoint is the only source. We will collect them via live response. For example, we could use the collect command in live response to directly download a specific file to our machine via the Defender portalreddit.com. For multiple or large files, a better approach is to compress them on the endpoint first, then collect one package. We can run a PowerShell script (signed by Microsoft) that zips up a target folder. PowerShell’s Compress-Archive can zip files, or if available, use tar (Windows 11 has tar and curl built-in now). We will use an internal script (uploaded to the live response library) to zip the local documents folder and any other target directories. The script can then place the password-protected zip in a temp location. After that, we invoke Defender’s file download to pull that zip up to the portal (the live response Download or GetFile command). This way, the data exfiltration from the endpoint happens via the Defender agent’s secure channel, which is likely seen as normal telemetry by network monitors.
• Volume and Splitting: If the local data is large, we might split it. The Defender live response might have size limits on file collection (often around 50MB per file via API by default, though that may be increased). If necessary, the script can split archives or we collect multiple zips by parts. Alternatively, we can use the endpoint’s own internet connection to send data out to an attacker-controlled server, but that would be a last resort if Defender collection fails, because a large outbound transfer might be more noticeable. Since we have Microsoft’s pipeline, using it hides the traffic within expected patterns (Defender agent already communicates regularly to the cloud; one more chunk of data isn’t obvious). We note that by doing this inside the authorized security channel, we avoid classic exfil detection like unusual destination or protocol – it’s literally communicating with Microsoft, which is what it does all day.

8.3 Impersonation/Sharing Method (Alternate):
Another creative path: Microsoft (as Global admin) could temporarily create a copy of the user’s OneDrive data or add a new owner to it. For example, they could add a stealth admin account as a co-owner of the OneDrive and then simply use OneDrive’s own sync mechanism to sync the data to another machine. However, that approach might leave an audit log (OneDrive admin addition is usually logged). We consider it but prefer direct Graph download as it’s cleaner. Similarly, we avoid making the user share files externally or sending them via email, as those would clearly pop up in logs or DLP.

8.4 Tools for File Collection:

• Microsoft-Native: Microsoft Graph API (OneDrive and SharePoint endpoints) as described is the main tool. Additionally, SharePoint Online Management Shell or PowerShell Graph SDK could be used to script the downloads. Since we are doing a red-team style op, we treat Graph API calls as our “tool” rather than needing a third-party utility.
• Open Source/Third-Party: One noteworthy tool is Rclone, an open-source utility that supports OneDrive and SharePoint connections. If we had a user’s refresh token or app credentials, we could use Rclone to sync the entire OneDrive to an attacker-controlled location. This is something an external attacker might do upon getting access: Rclone can run in headless mode and pull down all files. In our case, Graph API script achieves the same effect with possibly less footprint, but it’s worth mentioning Rclone as an option if we were to deploy something on the endpoint. We could also compile Rclone into a single EXE and run it via Intune, but launching an unknown EXE, even if it’s doing legitimate API calls, could trigger Defender’s suspicion (unless signed/allowed). Given our stealth constraints, we lean on Graph via trusted channels.
• Another red-team tool: “Snaffler” (an open-source .NET tool to find and grab files of interest). Attackers often run Snaffler to triage file shares and local drives. We considered using Snaffler on the endpoint to automatically find files with certain keywords or patterns (since it’s efficient). However, Microsoft Defender for Endpoint is known to flag Snaffler by name – running it out-of-the-box triggers a high-severity alert “Process loaded suspicious .NET assembly” because it matches the module name of a known toolkpmg.com. Researchers have shown that MDE’s detection on such tools can be evaded by simply renaming the assembly/module stringskpmg.com. We could recompile Snaffler under a different name (even something innocuous) to bypass that signaturekpmg.com. With MS help, we might not need to, but if we were going to use Snaffler, we’d definitely apply that trick to avoid the built-in detection (as KPMG researchers did, renaming “Snaffler” to something benign removed the alertkpmg.com). In summary, we won’t actually run Snaffler because we already pinpointed files via telemetry; but conceptually, if we needed on-disk discovery beyond what telemetry gave us, we’d use a modified/obfuscated scanning tool or just PowerShell, rather than a known hack tool binary.

8.5 Evasion in File Collection:
We must be cautious about a few things while collecting files:

• Defender Real-time Scanning: If we compress a lot of files on the endpoint, Defender AV might scan inside the archive or flag the action if any known malware signatures are in those files. Since these are research documents, unlikely to contain malware themselves. But as a precaution, we can instruct Defender not to scan our working directory by creating a temporary exclusion (requires admin privilege, which we have via SYSTEM context). However, adding an exclusion might itself be logged or disallowed by admin policy. Instead, since MDE is in passive mode (SentinelOne is primary), Defender’s real-time scanning might not even be fully on. EDR block mode is active, but that only responds to post-breach behaviors, not standard file archiving. We just ensure our compression tool is not flagged (using PowerShell’s built-in compress shouldn’t trigger anything).
• SentinelOne Telemetry: Although S1 won’t block, it will log file and process actions. Compressing hundreds of files might produce a pattern (lots of file read operations by powershell.exe or by 7zip.exe if we used that). This could look like data staging – some SOCs have alerts for processes zipping up many files (indicative of exfil or ransomware preparing data). We mitigate this by possibly chunking the operation: e.g., compress in smaller batches rather than one huge zip, and doing it slowly if time allows (to avoid a spike). If S1 has any ML that flags “bulk file access”, we want to be under the threshold or have it occur at a time SOC is less likely to see it in real-time.
• Network Exfil Noise: For the Graph API downloads, that network traffic doesn’t hit the endpoint. For any file we pull via Defender’s channel, it goes out over the endpoint’s internet to Microsoft. That is essentially HTTPS to Azure, which is normal for Defender. The volume might be larger than usual (if we pull many GB, maybe that stands out). However, we could throttle the download speed or break it up so it looks like extended telemetry. Additionally, if the SOC monitors network egress volume per device, a sudden upload of, say, 5 GB at 3 AM might raise eyebrows if they have anomaly detection. In a typical setup, they might not alarm unless extremely large. We could instruct Microsoft to temporarily rate-limit the upload or mark it as “expected backup traffic.” If extremely concerned, we could exfiltrate files via the cloud only (Graph direct) and not use endpoint network at all. We have flexibility: in fact, we may decide to do all file downloading via Graph from cloud storage to avoid any heavy lifting by the endpoint beyond packaging local-only files.
• Cleanup: After grabbing files on the endpoint, we will delete any residual artifacts (temp zips, scripts, etc.). In live response, there’s an option to delete files as well. We’ll securely delete if possible (though a simple delete is usually enough to avoid casual discovery). More on cleanup in Section 10, but as we collect, we already plan how to leave no trace.

By the end of this phase, we will have all the user’s documents from cloud and local sources exfiltrated. The SharePoint/OneDrive data likely constitutes the bulk of what the SOC might notice if done clumsily (due to volume), but our mix of cloud and endpoint methods with Microsoft’s network should keep it under the radar.

9. Collection Phase – Local Document Store & Other Data

While OneDrive covers most user documents, we also address any non-synced local data. “Local document store” could include:

• Files the user saved locally and didn’t sync (e.g., certain confidential files not meant to leave the machine).
• Application-specific data (maybe a research database, or output files from analysis software).
• External media currently connected (if any, like an USB with data).
• System info that could be indirectly useful (for example, we might grab browser saved passwords or cookies if we were expanding scope, but that’s out-of-scope here unless needed for further access – our mission is purely data exfil, not account takeover).

Our strategy:

• Targeted Search: From recon, we know the key directories. We will do an explicit check of C:\Users\<User>\Downloads (users often accumulate files there that aren’t moved to OneDrive). If large or interesting files exist, include them. Also check if the user has a C:\Users\<User>\Documents\ that isn’t empty (if OneDrive KFM wasn’t enabled). If it exists and has files, those are likely not synced – definitely include them.
• Special Software Data: If this is a research machine, perhaps they use specialized tools (CAD software, statistical programs) that save data in their own folders (e.g., C:\Projects or D:\). Our telemetry or a quick dir D:\ will show if a secondary drive has content. We won’t run comprehensive tools like Everything or search indexing; we’ll stick to where humans typically put files. Also consider Outlook local archives: some users keep old emails in PST files on disk. A search for .pst on the drive can find those. If found, we exfiltrate those as part of local files (though we already exported mailbox from cloud, PSTs might be older archived mail not on server). We will include any .pst or .ost files discovered, just to be thorough (they might be large though, but compressible).
• Credentials/Keys: Not core to docs, but if encryption is used (e.g., maybe they encrypted some files with EFS or have a password vault file), we might quietly grab those too for completeness. With MS help, we might even get the keys (if e.g. BitLocker key or EFS cert is escrowed in Azure AD). But again, that’s more espionage than the data exfil goal, so only if needed for accessing files.
• Staging and Packaging: As with OneDrive files, we compress local data for transfer. Possibly we merge it with the OneDrive package if not too large, or separate. For example, create local_docs.zip containing everything from non-synced locations.
• Defender for Endpoint Investigation Package (optional): Defender has a feature to collect an “Investigation package” which includes system logs, running processes, and potentially certain files for forensicsreddit.com. With Microsoft’s control, we could trigger an investigation package collection. This typically doesn’t grab user documents (mostly system information), so not directly useful for our goal. We mention it only because it’s something an IR team might use – in our case, not needed since we prefer to custom pick files.
• Live Response Scripting: If manual navigation is cumbersome, we’ll use a small PowerShell script to gather files. For instance, a script to recursively copy target directories to a staging folder (say C:\Windows\Temp\staged\). We ensure this staging folder is excluded from Defender scanning (maybe by design it might be in a global AV exclusion, but if not we assume passive mode means no active scanning anyway). Then compress that folder.

Data Verification: We will verify the integrity of what we collected (maybe by checking file counts or doing spot checks). We want to be sure we indeed got “all” documents. If the user had any unsynced files locked by permissions (unlikely on a single-user workstation), SYSTEM can still read them, so we’re fine.

At this point, combined with Section 7 and 8 results, we have:

• Full mailbox data.
• Full OneDrive/SharePoint data.
• All other local files of interest.

All exfiltration has been done either via Microsoft Graph direct downloads or via the Defender agent to the cloud. We’ve minimized any direct “upload to unknown server” which could have been flagged by network monitoring.

Now, having collected the data, we turn to ensuring we remain undetected – which means evading the various security controls and cleaning up traces.

10. Evasion of Security Controls

Throughout the operation, we implement specific counter-detection tactics for each security mechanism in place. This section details how we evade or minimize detection by Microsoft Defender for Endpoint (MDE), SentinelOne EDR, Intune compliance enforcement, audit logs, and SIEM correlations. We also cover how we avoid leaving persistent implants or forensic evidence.

10.1 Microsoft Defender for Endpoint (MDE) Evasion

MDE (in EDR block mode) is arguably the most sophisticated detection on the host. Even though its antivirus is in passive mode, its EDR sensors can flag malicious behavior and even block some actions. Our strategies:

• Living off the Land & Trusted Tools: We avoid using obvious malware or hacking tools that MDE would spot via signatures or heuristics. Instead, we leverage trusted system processes and Microsoft-signed tools. For example, using PowerShell for most activities (with well-crafted commands) appears as normal admin scripting rather than dropping unknown EXEs. If we need a custom binary (say, to run a capability that PowerShell can’t), we may use Microsoft’s cooperation to have it signed by a Microsoft certificate or executed via a trusted container (like a .NET reflection in a signed process). By doing so, we bypass typical code integrity checks and reputation analysis – MDE generally trusts Microsoft-signed code.
• Avoiding Known Malicious Patterns: We steer clear of behavior that Defender’s behavior analytics look for. For instance, we won’t inject code into other processes, we won’t attempt to disable security features, and we won’t scrape LSASS memory. Such actions would trigger immediate MDE alerts. Also, when using PowerShell, we run in constrained language mode when possible or ensure our usage doesn’t trigger script block logging alerts (though if script block logging is on, our commands would be recorded – but since we assume we have high privileges, we could also turn off logging or clear those records if needed). We keep PowerShell usage to tasks that a system administrator might do (archiving files, listing directories), rather than suspicious recon (like no Invoke-Mimikatz, no port scans).
• Utilize MDE’s Own Channels: By using Defender’s Live Response for actions, we inherently execute within the context of the Defender agent. This means many actions may be implicitly trusted or not subject to the same monitoring. For example, if we run a script through Live Response, MDE doesn’t self-report that as malicious (it assumes an analyst is doing it). We do need to be mindful: any actions we take are still occurring on the system, so if we did something truly bad, MDE might still catch it. But e.g., copying files and zipping them won’t look malicious. If any MDE alert did fire during our operation (say we slip up and a tool is detected), Microsoft can intervene in real time to suppress the alert. They could mark it as a false positive or prevent it from reaching the customer’s portal. However, our goal is not to trigger one at all.
• Signature Evasion: Where we do use tools, we modify them to evade static signatures. We already mentioned renaming .NET tool modules to evade the “suspicious assembly” alertkpmg.com. Similarly, if we were to use any publicly known tool (like Rclone or NirSoft utilities), we might recompile or alter them (change hashes, strip metadata) to avoid known hashes or signatures. With MS help, we could also whitelist the specific hashes in Defender (though that might leave a trace in tenant’s allow list if not careful). Simpler to just mutate the binaries enough that Defender doesn’t recognize them, or better, not use them at all and stick to built-ins.
• EDRSilencer (last resort): There exists an open-source red team tool called EDRSilencer that can detect and block EDR processes’ communications*areteir.comareteir.com. It specifically can target processes of many EDRs including Microsoft Defender and SentinelOneareteir.com. Essentially, if run with admin rights, it hooks or firewall-blocks the agent processes so they cannot send alerts out, effectively “silencing” the EDRareteir.com. If we were very concerned about any noisy step we plan to take, we could deploy EDRSilencer on the endpoint to temporarily cut off Defender’s cloud connection, ensuring no alerts or telemetry leave during that window. This is a tactic used by real attackers in 2024 attacksareteir.com. Drawback: If Defender’s service is blocked from communicating, the SOC might see the device as “missing telemetry” or offline if it lasts too long. A short outage (a few minutes) might not be noticed or could be attributed to network hiccup. We could time its usage for after hours. In our case, because we have cooperation, a cleaner method is to have Microsoft simply ignore or drop the alerts on their side. But if needed, deploying EDRSilencer for a quick data copy and then removing it is an option. We note it but aim not to use it unless a particularly risky action (like running a scanning tool that definitely triggers alerts) is absolutely needed. Given our plan avoids those, we likely won’t run EDRSilencer, thus avoiding the risk that the agent outage itself is flagged.
• Attack Surface Reduction (ASR) Rules: Windows 11 with Intune might have ASR rules enabled (like blocking PowerShell from creating child processes, etc.). These are part of Defender’s capabilities. In passive AV mode, some ASR rules might not apply (they need active mode usually). We will verify if any ASR rules are in effect via Intune policy. Assuming not, or that MS could disable them momentarily, we proceed. If they are on, we ensure our actions don’t violate them (for example, an ASR rule might block WinWord from spawning cmd – we’re not doing anything like that).
• Testing in Lab: Because of cooperation, we likely have an identical test environment or at least Defender in a lab where we can dry-run our tools. We will have tested any custom script or program to see if Defender flags it before deploying live, adjusting as needed. This way, we know ahead of time we’re not tripping Defender.

In summary, against MDE we rely on stealth via legitimate channels, renaming and obfuscation of any known malicious tools, and co-opting the agent’s trust. These combined mean Defender should either see nothing amiss or choose not to act on what it sees.

10.2 SentinelOne EDR Evasion

SentinelOne in telemetry mode won’t block us, but it’s still “watching” and recording. The SOC might receive alerts from SentinelOne’s console if it detects something it deems malicious (telemetry mode often still generates alerts/events, just doesn’t remediate). Our evasion overlaps with the Defender strategy but with some differences:

• No Tampering with S1 Agent: We avoid attempting to disable or modify SentinelOne’s agent. Doing so (especially without fully uninstalling) can trigger tamper alerts. SentinelOne has self-protection; even in telemetry mode, an attempt to kill its process or service will likely generate an alert to its console (and might not succeed without special methods). We will not stop the agent or unload drivers. The only scenario we’d interfere is via EDRSilencer as mentioned, which can block outbound traffic of S1 processes (so the agent keeps running, but can’t send data out). If we use that, it should be done stealthily and reversed quickly. But again, we plan to avoid needing it.
• Blend in with Normal Admin Behavior: Many EDR detections revolve around unusual behavior sequences. We tailor our approach to look like either standard IT activity or user activity. For example, running PowerShell is common, but running it to encode and run a big base64 payload is not (that would trigger an alert). We keep our PowerShell commands straightforward and even chunk them to avoid very long command lines that look obfuscated. If possible, we execute commands in pieces (so as not to have a giant suspicious one-liner). We can also hide our PowerShell window (use -WindowStyle Hidden) so if the user is around they don’t see a console pop up.
• Memory and Execution Patterns: SentinelOne’s telemetry might detect things like code injection or reflective loading of DLLs as suspicious. We avoid any need for that. We won’t use reflective DLL injection, process hollowing, or any advanced in-memory trickery. They’re unnecessary given our access. Everything will run either as a script or normal program.
• File Access Patterns: SentinelOne will log if a process reads many files rapidly (like ransomware would, or a bulk copy might). We mitigate this by rate-limiting our file collection if feasible. Instead of reading thousands of files per second, maybe our script introduces slight delays or processes one directory at a time, giving a more human pace. This can avoid triggering any “mass file modification” heuristic. Also, by doing it under a legitimate process (PowerShell or the OneDrive sync engine itself), even if it’s detected, it might be categorized as less severe.
• Using Approved Tools: If the environment specifically allows some admin tools (maybe they have Sysinternals or 7-Zip installed), we could leverage those rather than introducing new ones. For instance, if 7-Zip is already on the system (some orgs include it), using it to create archives is fine and likely not flagged. If not present, we rely on built-in zip as discussed.
• Monitoring S1 Console (if possible): With Microsoft’s reach, we might not directly see SentinelOne’s alerts (since it’s a third-party product), but if the customer’s SOC aggregates SentinelOne alerts into Sentinel SIEM or similar, Microsoft might catch that. Alternatively, since it’s a lawful operation, perhaps the organization’s higher-ups allowed Microsoft to silently query the S1 console for any hits during the op. This is speculative – likely not, as it’s covert even from them. So we operate under assumption we can’t see S1’s brain, only predict it. SentinelOne does have known detection analytics – e.g., it may flag Mimikatz strings, or unsigned drivers being loaded, etc. We simply avoid anything known to be suspicious.
• Post-Operation Agent State: We ensure SentinelOne remains functional after we’re done. We don’t want the agent to crash or be left in a disabled state, as that would be noticed. So we won’t, for example, attempt to unload it or use an exploit on it. If we used EDRSilencer to block its network, we will unblock it and let it reconnect. Any backlog of telemetry will then send. However, if we did something malicious while it was blocked, and then unblock, that telemetry might go out and alerts could fire retrospectively. That’s a concern: EDRSilencer stops the sending but not the recording locally. The agent might queue the events. Once connectivity restores, it sends them. So using EDRSilencer only delays detection unless the plan is to keep it blocked until we wipe evidence. Given that complexity, our plan is to not rely on blocking S1 at all, instead just not doing things it would scream about.
• Cleaning S1 Telemetry (hard): Unlike Windows logs, one cannot easily clean an EDR’s internal telemetry without hacking the agent (which is extremely difficult and beyond scope). SentinelOne stores data in a local database but encrypted/secured. We assume anything we did is likely recorded. Our best mitigation is to ensure nothing we did stands out enough to be noticed by analysts in that data. Because if there’s no alert, the only way they’d catch us is by proactively hunting through logs, which is unlikely unless they have a reason. We aim to give them no reason. After the operation, if some investigation occurs, we can only hope our traces in S1 logs look like normal admin or system activity. For instance, “PowerShell.exe launched, did some file reads, network to Microsoft IPs” – that could be Windows Update or Defender actions, etc. We’ll try to use process identities that overlap with legitimate ones (maybe even running under the context of the system security tools).

In short, SentinelOne is a silent observer in our scenario; our job is to not do anything obviously malicious for it to flag. By sticking to offensive actions that resemble regular usage, we greatly reduce S1’s ability to mark them as malicious. Telemetry mode gives us leeway because even if it sees something borderline, it might just log it without raising an incident.

10.3 Intune Compliance and Policy Evasion

Intune’s role is more preventive – ensuring the device stays in compliance. Non-compliance could lock us out via Conditional Access, or send an alert to IT. We ensure:

• Maintain Compliance State: We will not disable or uninstall any required security agent. Defender AV will remain on (passive) and SentinelOne stays running. We won’t turn off BitLocker or firewall. Essentially, none of the compliance checkboxes should flip. If compliance policies include “Device threat level” integration with Defender for Endpoint, we must avoid raising the device’s risk score. Typically, if MDE finds high or medium threats, it can mark device as “at risk”. Because we intend MDE to see none or benign activity, this risk level stays “Secure”. Thus conditional access won’t kick in to block the device.
• No Policy Violation: Intune might enforce certain configuration (like blocking execution of unknown EXEs via Windows Defender Application Control (WDAC) or blocking scripting via Attack Surface Reduction rules). We accounted for ASR earlier. If WDAC is in audit mode or not present, no issue. If WDAC is enforced and only signed code runs, our approach of using signed/MS code handles it. If we absolutely needed to run an unsigned binary on a locked-down device, we could either sign it with a cert that is trusted (with MS help perhaps, or using an existing signing service in the org if we compromised one – but here we have MS who could sign it directly with Microsoft’s cert which is universally trusted by WDAC). However, we haven’t planned any such custom binary in this op; everything can be done with what’s there.
• Stealth Intune Use: If we used Intune to push a script, we need to consider Intune’s audit. Normally, Intune logs which admin account uploaded a script and when it ran on devices. If an internal admin reviews Intune logs, a mysterious script or app deployment could raise questions. Here’s where Microsoft’s cooperation is key: they might inject the script execution in a way that bypasses normal logging (like using a backend interface or the Intune Management Extension in a special mode). Alternatively, they may use an Intune functionality that is common (like initiating a “Sync Machine Policy” or a device sync) that triggers our script which was pre-staged. For the purpose of this playbook, we assume the Intune method is done as covertly as possible. After use, any script or app deployed will be removed. If possible, we name the script something benign (“Update policy script #1234”) so even if seen, it doesn’t scream “malware”.
• No Lasting Mods: We will not change Intune configuration on the device in a lasting way. For example, we won’t remove the device from Intune (obviously), nor change its compliance status deliberately. If we needed to disable something like ASR or a setting for our task, we’d re-enable it immediately after or do it in memory so the compliance check doesn’t catch a policy deviation. The timeframe of our operation is short enough that the Intune check-in (which is typically every 8 hours for compliance evaluation) might not even happen during our window. Even if it did, nothing should appear out of order.
• Conditional Access Bypass (if needed): If our actions required an additional cloud login (like if we logged in as the user from a different machine to use Graph, normally CA might block that because the device is unknown), Microsoft can bypass that by either marking our session as trusted or by using the existing device identity. For instance, we could generate a PRT (Primary Refresh Token) from the device or use the device’s identity token to call Graph as that user, which satisfies CA because it appears from a compliant device token. However, since we got access through back-end, we likely don’t hit CA at all.

Overall, Intune is more of a guardrail; by staying within those guardrails (no obvious policy breaches), we remain fine. The only Intune-specific detection could be an admin seeing the device go “not compliant” or weird activity, which we have ensured won’t happen.

10.4 Logging and Audit Evasion

Even if we avoid security alerts, logs will be generated of our activities. A truly covert operation may require cleaning or suppressing those logs. We consider logs on various levels:

• Windows Event Logs: Our actions (especially if using PowerShell) can generate event log entries:
  
  • PowerShell has optional logging (module logging, script block logging). If enabled, our commands might be recorded in Event Log (Microsoft-Windows-PowerShell/Operational). We can check via live response if those logs are on. If so, after operation we could clear or remove specific entries. Clearing entire PowerShell log might be noticed (MDE often alerts on log clearing as an IOC). Instead, we might disable the logging at the start (Set-PSDebug -Off or removing associated GPO via registry) to stop recording, then re-enable after. Or simpler, run our PowerShell under a context that isn’t monitored – e.g., the System account might not have the same logging applied as user context (depending on how logging was configured). This gets very granular; a safer route is to do minimal scripting or at least nothing that looks suspicious in logs. If needed, Microsoft could remove the specific log entries from the machine after the fact by editing the event log database (security agencies have been known to have such capabilities, though that’s not publicly documented).
  • Other logs: File copying might create entries in Windows “File Audit” logs if auditing is configured on sensitive folders. Unless this org specifically audited every file access (unlikely due to volume), we should be fine. We’ll assume no heavy file system auditing was in place, but if it were, those logs likely go to the SIEM. We can’t realistically clean SIEM, but we can try to delete local Security log events if we know the IDs. However, clearing Security log triggers event ID 1102 which itself is suspicious. Instead of clearing wholesale, one could selectively remove events with tools, but that’s essentially using a “log wiper” tool, which itself might be flagged by EDR. Given our stealth so far, there may be no critical events to wipe.
• Defender for Endpoint logs: These are in the cloud (Defender portal). If any alerts were generated, MS can delete or mark them benign. But if none, then just raw telemetry exists and is not easily accessible to the customer unless they specifically hunt for it. Microsoft likely won’t retroactively purge raw telemetry for one device (that’s not trivial and not usually done), but also customers rarely get raw telemetry except via advanced hunting. If an investigation happens, they could use advanced hunting to find evidence of our activity (like, show all PowerShell execution or archive creation events). We rely on blending in to not raise that investigation in the first place. If absolutely needed, since MS runs the service, they have theoretical ability to remove certain records, but that’s extreme and we avoid needing it.
• SentinelOne Logs: As noted, we can’t clean those without extreme methods (which might break the agent). We accept they exist and count on no one scrutinizing them in time. If things got hot, and we had admin rights on the machine, we could uninstall the SentinelOne agent entirely (with the cooperation we might have the tamper-proof uninstall password). Uninstalling it would remove logs from that point onward and possibly its local store. But uninstall is definitely visible to the SOC (the agent would report being deactivated). So that’s not an evasion; that’s burning the operation. So we won’t do that.
• Office 365 Audit Logs: These logs record activities like file accessed, mailbox accessed, etc., in the Microsoft 365 compliance center. Our usage of the Graph Export API doesn’t log mailbox readsoffice365itpros.com. If we accessed OneDrive files via Graph as an admin or app, normally each file access might log an FileAccessed event (if the tenant has that enabled). But because our method might be seen as “System” or “Compliance” access, it might bypass logging. If not, a large number of FileAccessed events by an admin account in a short time could be noticeable. Mitigation: have Microsoft classify those log entries in a way the customer can’t see (for example, if it’s done under Microsoft’s internal admin context, maybe those events don’t show up to the tenant – similar to how eDiscovery by Microsoft under a warrant might be hidden). The CLOUD Act likely means Microsoft can avoid exposing those actions in the customer’s audit logs, preserving secrecy.
• Azure AD Sign-in Logs: If we used a service account or custom app to do Graph calls, there will be entries in Azure AD sign-in logs for that principal. For instance, “App X accessed Graph as User Y, succeeded, from IP ...”. With cooperation, those entries can be filtered from the UI or marked in a way that only Microsoft sees. If not, and an admin did a deep review, they might see an unusual sign-in at odd hours by an app ID they don’t recognize. Ideally, Microsoft uses something like their internal “Service” identity that doesn’t surface. We won’t have control over this directly, but it’s assumed in the scenario that the legal process allows them to mask it.
• Time to Live for Forensics: Our operation is one-time and short-lived, but logs can survive. If the target later suspects something and does a forensic analysis, they might find clues (maybe event logs showing our script execution, timelines from EDR telemetry). We attempt to reduce that footprint:
  
  • We may delete any scripts or executables we introduced.
  • We may wipe our command history (for instance, PowerShell history file in user profile if we ran as user – though we mostly run as System where interactive history isn’t kept).
  • If we made any temporary user accounts or credentials (not in this plan, but if we had), remove them.
  • Clear any scheduled tasks we might have created (none here, since we do live actions).
  • Remove any files we staged on disk (like the staged folder or zips after uploading).
  • Possibly flush DNS cache if we connected to unusual domains (though we mostly connect to Microsoft endpoints, which is normal).
  • Remove any entries from MRUs (most-recently used lists) if we opened any documents with an editor (we didn’t, we just copied, so no Office app usage).

In essence, we aim to leave the endpoint exactly as we found it, with no new services, no lingering processes (once we disconnect, our PowerShell or script stops), and no obvious errors.

10.5 Non-Persistence Measures

Non-persistence is fundamental: we do not implant backdoors or continuous access mechanisms. Once data exfiltration is done, our access channels are closed:

• If we used an Intune script or Defender session, those are one-time. We will terminate the live response session. We ensure any remote tool (like if we had a C2 agent injected) is killed and removed. In our plan, we didn’t use a traditional C2 agent (like Cobalt Strike beacon) precisely because that’s persistent and detectable. We stuck to “living” off existing agents (Intune, Defender).
• We do not leave scheduled tasks, services, or startup items. Many red team ops leave a backdoor to come back – not here, because it increases chance of later detection. Our assumption is we only needed one-time grab (since legal authority can be sought again if needed).
• The device and user credentials remain uncompromised from the user’s perspective. We haven’t stolen their password or tokens for later use (we used cooperation to impersonate, but didn’t actually need to trojan the user’s account for ongoing access). That means post-operation, there’s no need for the user to change passwords or any indicator to them.
• We double-check that any metadata we might have altered is reverted. For instance, if we changed a file’s “last accessed” timestamp by opening it, that could be a tiny clue. If we have the ability, we might restore original timestamps on files (PowerShell can do that) if we think anyone would look. That’s very low risk of ever being noticed but demonstrates thoroughness.
• If Microsoft added our account to any groups or roles for access, they will remove it immediately after. For example, if a global admin was temporarily added to the user’s OneDrive as site admin to read filesreddit.com, that membership is revoked once done. So the customer’s admin won’t find an extra owner lingering on the OneDrive later.
• Any tokens or keys we used (like an app client secret) should be invalidated post-op so they can’t leak or be reused.

By not persisting, we minimize the chance of long-term discovery. The operation becomes a snapshot in time that is easy to miss unless someone was actively watching at that time or doing a detailed retrospective analysis later with a reason to suspect.

11. Detection Risk Analysis

For each phase of the operation, we assess the probability of detection by the organization’s security controls and SOC, considering typical Canadian public-sector security setups. We use qualitative ratings (Low/Moderate/High) and rationale:

• Initial Compromise (Intune/Defender access): Risk: Low-Moderate. Since we leverage built-in management channels, there is no malware drop or exploit to catch. If done correctly, the SOC might not see anything at all. The only potential flag is if an admin happens to notice an unusual Intune deployment or a Defender live response session in the portal. Public-sector SOCs usually focus on alerts, not routine admin actions. Unless they have change monitoring on Intune (rare), this step should fly under the radar. With Microsoft’s help, it’s likely invisible. Moderate risk only if an alert admin is looking at audit logs during that window.
• Reconnaissance Phase: Risk: Low. Most recon uses cloud telemetry and benign queries. Searching Defender logs via Microsoft backend has no customer visibility. On-device recon, like directory listings, is very normal activity (every login does that for profile loading, etc.). No active scanning or port scanning that would trigger IDS. So the chance of detection here is negligible.
• Mailbox Export: Risk: Very Low. The Graph mailbox export occurs in Microsoft’s cloud where the customer cannot see it (and it leaves no audit trail by design as of 2025office365itpros.com). The user won’t notice anything in Outlook. The SOC won’t get any alert because it’s essentially an out-of-band copy. Unless the customer has some third-party M365 monitoring that somehow catches anomalous mailbox access (and given the audit gap, they wouldn’t), this is practically undetectable to them.
• OneDrive/SharePoint Exfiltration: Risk: Low (with Graph via backend), or Moderate (if large download visible). Using Graph under the hood, especially if done from Microsoft’s side, likely looks like either the user or a trusted app accessing files. Cloud App Security might flag “mass download” if it interprets it as the user doing it from an unusual location. But because we can masquerade the origin, this can be mitigated. If we did it via the endpoint (e.g., copying to external server), risk would be higher due to network monitoring. But we largely avoid that. The volume of files is the main concern – if hundreds of files are accessed at 3 AM, some anomaly detection might catch that. Public sector SOC could have MCAS policies for impossible travel or large download. However, if our access originates from the same region/IP range, it may not trigger. On balance, using sanctioned methods, this phase is likely not noticed in real-time. A diligent admin could theoretically see a spike in SharePoint usage metrics, but they’d have to look for it.
• Local File Collection: Risk: Low-Moderate. This involves reading many files and compressing them. On the endpoint, that could produce some load. If the user or any monitoring notices high CPU/disk at an odd hour, they might investigate. EDR telemetry will record the file access – if the SOC has advanced hunting queries looking for unusual mass file access or archive creation, they could catch it. Many SOCs don’t have such proactive hunts unless after an alert. SentinelOne might throw a contextual alert like “suspicious activity – possible data staging” if it correlates many files read by a process. It’s not known publicly if S1 does that by itself in telemetry mode. Given no prevention, likely not immediate. So detection during operation is unlikely. Later forensic review could uncover it (like “hey, why did Powershell read all these files?”). Without cause, they probably won’t look at that level. We mitigate to keep risk low by chunking and using normal tools.
• Defender for Endpoint (MDE) Alerts: Risk: Low if plan followed, High if mistake made. If we adhere to not using known malicious tools and patterns, MDE should stay quiet. A mistake (like running an unaltered hacking tool) could instantly fire an alert (High risk in that scenario). But we’ve accounted to avoid those. Considering the KPMG finding: running something with a known malicious name triggered a high alertkpmg.com, which we circumvent by renaming or not using those toolskpmg.com. So expected risk from MDE is low. If an alert did fire and Microsoft didn’t catch it in time, the SOC would definitely investigate (since MDE is integrated and they trust those alerts). That’s why we’re very cautious here.
• SentinelOne Alerts: Risk: Low-Moderate. Because it’s telemetry mode, SentinelOne may still raise alerts in its console (just not act). If its heuristics flag something, the SOC might get an email or see it on their dashboard. Examples might be “PowerShell performed potentially malicious file operations” or “Suspicious process injection” (though we avoid injection). We assume moderate risk if we were to do something like run an unknown binary (S1 might label it as ‘New malware’ or at least suspicious). By sticking to PowerShell and known tools, risk is low – S1 will log but perhaps not alert. The public sector SOC may not be watching the SentinelOne console actively if they rely on Microsoft tools primarily. If they do, they’d have to correlate that the activity is bad. Given no obvious harm done (no ransomware, no system change), they might not react to logs alone.
• Intune/SIEM Correlation: Risk: Low. The SIEM (if Microsoft Sentinel) would correlate multiple signals. If we’ve done well, there aren’t many signals to correlate. Possibly, unusual time of activity plus heavy file access plus data egress could be correlated by a UEBA (User and Entity Behavior Analytics) system. Many organizations do not finely tune UEBA, and such anomalies often need distinct alerts to correlate. Since we produce minimal distinct alerts, correlation won’t have much to link. Intune logs might show “script executed”, but Sentinel wouldn’t automatically flag that as an incident. Only if an analyst manually correlates “At 2:00 AM, a script ran on Alice’s PC and then a bunch of files were accessed and some data sent out” would they piece it together, and that requires hunting mindset without alerts – unlikely without a reason.
• User Discovery: Risk: Very Low. The user likely won’t notice anything. We schedule off-hours. There will be no UI pop-ups or password prompts. The only theoretical things a user might notice after the fact: perhaps OneDrive might show “file accessed at time X” if they check version history, but that’s buried. Or if we cause OneDrive to sync, maybe an icon shows sync activity – but user is away. CPU usage might spike but if at night, irrelevant. So user-generated detection is near zero.
• Post-Operation Audit/Incident Response: This is outside immediate detection, but if later (days or weeks) someone suspects data leakage, they might audit logs. At that point, risk of them finding evidence depends on what’s left. If our cleanup is good, they’ll have a hard time. But assume they eventually involve Microsoft. Microsoft might then reveal or hint (depending on gag orders, etc.). But within the constraints of our operation, we consider that out-of-scope; presumably if it’s a national security letter type scenario, the target won’t ever be told.

In summary, the highest risk of detection is during the operation by automated security tools (Defender or SentinelOne) if any of our behaviors trigger their analytics. We put heavy emphasis on avoiding those triggers. With that caution, the probability of detection in real-time is very low given full MS cooperation. A typical Canadian public-sector SOC, relying on default alerts, would likely see nothing amiss. They might only uncover this if they performed a targeted forensic investigation after the fact (which would require external suspicion).

To put in perspective: The operation’s most “noisy” aspect is copying files, which could at worst look like some automated backup or indexing job. Nothing destructive or overt like malware execution occurs. Thus, the SOC would need to be extremely proactive to catch it, which most are not without prompts. Therefore, we assess overall detection risk as low, with specific potential points mitigated as described.

12. Tactical Tooling Options

Throughout the operation, we have referenced various tools and methods. Here we summarize the key tools, both Microsoft-native and open-source, that can be employed, and their purpose in this playbook:

Microsoft-Native Tools & Methods:

• Microsoft Graph API: The Swiss-army knife for cloud data. Used to export mailbox content (via Mailbox Export API) and to enumerate/download OneDrive/SharePoint files. It’s a native interface that with proper permissions allowed us to exfiltrate data without custom malwareoffice365itpros.com.
• Microsoft Defender for Endpoint (MDE) Live Response: Gives a remote shell on the endpoint for direct control. We used it to execute PowerShell commands and to fetch files from the device securelyreddit.com. It’s part of the Defender security suite, so using it raises no suspicion by itself.
• Intune Management Scripts: Allows running PowerShell or other installers on the endpoint via Intune policy. We could deploy a custom script to perform actions locally. This leverages Microsoft’s device management pipeline, appearing as IT action.
• Azure AD / Entra ID Administrative Actions: This includes adding our account to roles (e.g., eDiscovery Manager, or SharePoint admin) or generating tokens to impersonate the user. These administrative moves were done covertly by Microsoft, effectively giving us legitimate access routes.
• Office 365 Content Search/eDiscovery: As a backup, using compliance center eDiscovery to search and export mailbox or files. We opted for direct Graph export instead (no audit logs), but Content Search is a native option if we had admin access.
• OneDrive Admin Links: A global admin can generate a link to access a user’s OneDrive directlyreddit.com. Microsoft could use that to browse or download files as needed. It’s a web-based method; we primarily automated via Graph, but this is another native approach.
• Compress-Archive (PowerShell) and other OS commands: We rely on built-in commands for compression, file copying, etc., to avoid third-party binaries. Windows 11’s PowerShell 7 or Windows PowerShell have the needed cmdlets to zip and transfer files.
• Microsoft Sentinel / Monitoring (Blue Team Perspective): While not a tool we actively use, we considered their use. E.g., if we triggered an alert, Sentinel would correlate it. We mention it to highlight what we avoided rather than something we utilized.
• Microsoft Certificate Signing: Implicitly, if we had a custom binary (none in this plan), Microsoft could sign it with a trusted certificate. That would help it bypass Defender’s SmartScreen and possibly WDAC. We didn’t explicitly need to do this since we stayed file-less for the most part, but it’s a tactic available under cooperation.

Open-Source / Red Team Tools:

• EDRSilencerareteir.com: An open-source tool to neutralize EDR/AV by blocking their communications. It supports SentinelOne and Defender among othersareteir.com. We considered it for temporarily preventing our actions from being sent to SOC. It’s a risky but effective evasion tool if used briefly and undone, to keep the operation quiet while it runs.
• Snaffler (modified): A file discovery tool useful for quickly finding interesting files. Out-of-the-box it’s detected by Defender due to its known name, but by renaming and recompiling it (e.g., change module name to avoid Defender’s signaturekpmg.com), it can be used without alert. We ended up not needing it because we got file info from telemetry.
• Rclone: A command-line tool that can sync cloud storage (including OneDrive) to local. Attackers often use it for data theft because it’s efficient and can use official APIs. If we had user credentials or an OAuth token, Rclone could have pulled the entire OneDrive to an external server. In our scenario, Graph script achieved the same within Microsoft’s environment. But Rclone remains an option if one were operating purely from the endpoint outward.
• MailSniper: A penetration testing tool designed to search and export emails from Exchange (via EWS or Graph) given credentials. With our direct Graph access we didn’t need it. If an attacker had user creds or token, MailSniper could iterate through mailboxes. It’s largely superseded by Graph usage, but relevant historically.
• Cobalt Strike / Beacon: A popular red team command-and-control framework. We mention it to note we intentionally did not use a Cobalt Strike beacon or similar payload on the host, because those are heavily detected by EDRs. In some ops, one might have a Beacon injected for control. Here, Intune/Defender live response took that role, so no need to deploy C2 malware, which drastically lowers detection chances.
• Mythic or Covenant: Other C2 frameworks (open-source) that could have been used if we wanted our own persistent control channel. Again, we avoided these for stealth. They are tools in a red team toolkit, but using them would risk detection by behavior analytics. With cooperation, using them is unnecessary overhead.
• 7-Zip Portable: An open-source archiver. If not already installed, a red team might bring in a portable 7z.exe to compress files. We opted for PowerShell’s native compression, but 7-Zip is faster for large data and could be used if whitelisted. One caution: an unknown 7z.exe might be flagged by AV. If we wanted, we could rename it to something benign or even sign it. In some ops, teams rename 7z to “notepad.exe” or similar to blend in.
• Exfiltration Over Alternative Channels: Not exactly a tool, but some attackers use HTTP POST to web servers, DNS tunneling, or cloud services (like uploading to Dropbox, Google Drive, etc.). We didn’t need those because we had direct pipeline. But for completeness: If not cooperating with MS, an attacker might compress data and upload to an Amazon S3 bucket or use DNS exfil if environment was super restrictive. Those techniques usually trigger alerts (unusual network dest, data to cloud not in allowlist, etc.), hence not chosen here.

In practice, our approach favored Microsoft’s native “tooling” as the primary means – leveraging existing infrastructure as our tools. This meant we used fewer traditional hacker tools, which is a core reason for our stealth success.

To tie it together, the combination of Graph API for cloud, MDE/Intune for endpoint, and disciplined use of open-source tools (only if necessary, and deeply obfuscated) provides a comprehensive toolset to achieve objectives. All the heavy lifting is done by Microsoft’s systems or carefully crafted scripts, minimizing the footprint of any third-party binaries in the target environment.

13. Sovereignty, Visibility, and Irreversibility Considerations

Finally, we address the unique implications of conducting this operation under U.S. legal authority (FISA/CLOUD Act) on Canadian-held data, and what that means for the customer’s visibility and our actions’ irreversibility.

Data Sovereignty Trade-offs: This operation underscores that data stored in Canada with a U.S.-headquartered provider (Microsoft) is not immune to U.S. legal reachtheregister.com. Microsoft’s admission that it cannot guarantee data sovereignty in face of CLOUD Act demandstheregister.com is exemplified here – the data was handed over to us without the Canadian customer’s consent or knowledge. For the red team simulation, this means we had an easier time (we didn’t need to find zero-days or heavily evade network controls; we came through the service provider). But from a customer perspective, this is a bit of a blind spot: even if they had impeccable security internally, the cloud provider itself facilitated the data extraction.

Customer Visibility (or Lack Thereof): The target organization will have near-zero visibility into this operation:

• The usage of Microsoft’s internal channels and suppression of logs means the customer’s SOC likely sees nothing in their security dashboards. Even their global administrators would not see the mailbox export or the bulk file access if those were done under Microsoft’s internal context or maskedoffice365itpros.com.
• If some logs are visible (e.g., a record of a compliance search or a strange admin login), they may not be readily attributed to what actually happened. Additionally, Microsoft often issues gag orders with FISA warrants, so they legally cannot alert the customer. The SOC might just see “no alerts, all quiet” while in reality data was taken.
• Implication: In a real scenario, this stealthiness preserves the covert nature, but it also erodes the customer’s trust in their ability to detect breaches. In post-analysis, it may prompt questions about relying on foreign cloud infrastructure for sensitive data.

Irreversibility of Data Exfiltration: Once we have exfiltrated the data, the deed is done – the customer cannot “un-exfiltrate” it. If they were never aware, they won’t even take remediation steps. From our perspective:

• We ensure no persistent access remains, so in theory, after we disconnect, the environment goes back to normal. There’s nothing to remediate on their side (because we left no malware).
• However, if this were discovered later, the customer cannot retroactively secure that data. They’d have to assume everything in that OneDrive/mail is compromised. That could have legal or privacy implications depending on the data type (e.g., if personal info was in there, technically a breach occurred but they won’t know to report it).
• Because of the legal framework, the organization might never be allowed to know (national security investigations often remain classified). That means irreversibly, that data is out of their control now.

Sovereignty and SOC Monitoring: Many Canadian public-sector organizations count on data residency in Canada and sovereignty assurances. This operation bypassed those by leveraging cloud law. It demonstrates that even with robust local SOC monitoring, certain accesses facilitated by the provider at a global level can be invisible. The SOC might notice peripheral evidence at best, but not the content or the fact data was transferred out of country. Microsoft’s transparency reports claim no EU (or Canadian) customers have been affected by CLOUD Act requests yettheregister.com, but that’s possibly because of secrecy or because it’s rare. In any case, if it happens, the customer is effectively blinded.

Reversibility of Actions: On the technical side, we made minimal changes which we mostly reversed (deleted temp files, etc.). There is little for the customer to “restore” except maybe some log entries we suppressed (which they wouldn’t even know to restore). The only irreversible thing is the potential knowledge or advantage gained by whoever obtained the data. In a red team sense, we got the crown jewels; if this were an adversary, they could now leak or use that info. There’s no way for the customer to rollback that exposure.

Customer Mitigations (if they knew): It’s worth noting that the only way to mitigate such covert operations would be:

• To minimize reliance on single vendors for everything (e.g., consider sovereign cloud or customer-managed keys that even MS can’t access easily). If the data were end-to-end encrypted with a key Microsoft doesn’t have, a Cloud Act request might not get plaintext (though Microsoft could compel to push a malicious update to grab keys from endpoints, etc.).
• Increase monitoring of administrative and third-party access. But if the provider themselves is executing, it’s an uphill battle.
• Possibly keep extremely sensitive data off cloud entirely (air-gapped). But that’s not practical for most workflows.

For our report’s context, these are points for completeness, illustrating how a lawful intercept operation differs from a standard external attack: it leverages trust and legal channels to be as quiet as possible.

No Notification & Gag Order Effects: Because Microsoft is cooperating under FISA, the customer will not be notified (Microsoft fights to notify if possible, but usually national security letters come with gag orderstheregister.com). So the organization’s security team remains in the dark by design. This is a fundamental difference to a typical incident where eventually some indicator tips them off and they can respond. Here, success means the target remains unaware indefinitely.

Ethical/Policy Note: While outside the direct scope of the technical playbook, it’s worth noting that such operations toe the line on user trust in cloud services. Microsoft has processes to resist broad or unfounded requeststheregister.com, but in our scenario, presumably all legal hurdles were cleared for this targeted case. The team executing this should be aware of the sensitivity and ensure no unnecessary data is taken (stick to scope) to minimize collateral impact.

In conclusion, from a red team perspective, full Microsoft cooperation enabled an extraction that bypassed nearly all of the client’s defenses and visibility. The operation exploited the “God mode” that a cloud provider (under legal duress) has in a tenant’s environment. The customer’s SOC likely saw nothing, and the data is now in our possession outside of their jurisdiction. The trade-off of using such a method is precisely that – it capitalizes on the gap between cloud sovereignty promises and legal realitiestheregister.com, granting us a virtually stealth success that would be extremely hard to achieve via purely technical means in a well-defended environment.

14. Conclusion

Summary of Operation: We successfully simulated a covert red team operation that exfiltrated a user’s entire trove of data (OneDrive/SharePoint files, local documents, and mailbox) from a highly-secured Windows 11 workstation, all without detection. By partnering with Microsoft under lawful authority, we bypassed traditional security barriers and used trusted channels (Graph API, Intune, Defender) to carry out the mission. Each phase – from initial access to data collection and exfiltration – was carefully executed to avoid triggering Microsoft Defender for Endpoint, SentinelOne EDR, Intune compliance checks, or audit alerts. We leveraged cutting-edge techniques available as of October 2025, including the Graph mailbox export API which leaves no audit traceoffice365itpros.com, and demonstrated evasion tactics like renaming tool signatures to fool Defenderkpmg.com and even discussing tools like EDRSilencer to mute EDR communicationsareteir.com.

Detection Probability: The likelihood of real-time detection by the organization’s defenses was assessed to be very low given our stealth measures. We avoided known indicators and kept our footprint minimal and “normal-looking.” In a typical public-sector SOC with Microsoft-centric monitoring, our activities would blend into noise or appear as routine system behavior. Without any high alerts from Defender or SentinelOne, the SOC would have no immediate reason to investigate. The success of this operation highlights a paradigm where the best way to hide an attack is to make it look like it didn’t happen, or like normal operations. By using Microsoft’s own infrastructure against itself (albeit lawfully), we achieved that invisibility.

Key Learnings: This exercise emphasizes:

• The power of supply-chain/insider access: When the cloud provider cooperates, even the strongest endpoint security can be circumvented quietly. No malware can often be more effective than the best malware, if you can utilize existing trusted tools.
• Modern security feature bypasses: Even advanced tools like MDE have blind spots – e.g., reliance on known bad signatures which can be evaded by minor changeskpmg.com. Attackers (or red teams) continuously find and exploit such gaps.
• Importance of comprehensive monitoring: The operation exploited holes in auditing (Graph API with no logsoffice365itpros.com) and in assumptions (trust in cloud operations). Organizations should understand those gaps; for example, push for transparency on admin actions or ensure some out-of-band logging of data access by providers.
• Transient, file-less techniques: We employed non-persistent, in-memory or ephemeral approaches, leaving little trace. This is increasingly the norm for real threat actors to avoid leaving malware footprints.

Recommendations for Defense: (If we were advising the target based on this red team) – They should consider measures like:

• Enabling and reviewing unified audit logs for unusual mass access (even if via admin). If possible, get alerted when large volumes of files are accessed by any account, even an admin.
• Deploying insider risk tools that might catch anomalous data aggregation behavior on endpoints (like, a user rarely zips files – if one day a zip of 1000 files occurs, flag it).
• Implementing “customer-controlled key” encryption for extremely sensitive data, so that even Microsoft can’t decrypt content readily. That way, a Cloud Act request yields ciphertext unless law enforcement also compels the key (which adds a layer).
• Periodically auditing accounts with high privileges and their activities – even those of Microsoft support personnel if any (some orgs can request logs of Microsoft’s access under certain support scenarios).
• Using multi-EDR or cross-telemetry analytics: e.g., correlate endpoint and cloud signals better. If a user’s device is offline but their account is downloading GBs from SharePoint, that might be an anomaly to catch.
• Acknowledge that a determined adversary with cloud-provider-level access is extremely hard to detect – thus focus on prevention and minimizing what data would be accessible in such a scenario.

Irreversibility: The data obtained is now in presumably U.S. custody and cannot be returned unseen. The target’s environment, however, remains uncompromised from their point of view – no clean-up needed on their side because they don’t even know. This is a double-edged sword: great for covert ops, but if used maliciously, horrifying for the victim.

The playbook shows how a red team (or nation-state actor) in 2025 can utilize the intersection of cloud and endpoint security features to their advantage. It balances technical steps and strategic silence at each turn. Every action was structured with an eye on not tripping detectors, from the first entry to the final exfiltration. By following this structured approach, we achieved the mission goals and remained undetected, fulfilling the core requirement of a covert operation.