Documented Campaigns — Espionage and Supply Chain

Espionage: the collection cadence

The defining characteristic of espionage campaigns is mechanical regularity: same resource, same time, same device, repeating over weeks with the precision of an automated process. M-Trends 2026 reported that espionage-related intrusions had a median dwell time of 122 days. The attacker is not trying to complete an objective and leave. They are maintaining ongoing access to data that updates over time.

Ransomware and espionage require separate detection pipelines. A program optimized for one is blind to the other.

The operator accesses the target mailbox every Tuesday and Thursday morning. They download updated strategy documents every two weeks. They check the R&D SharePoint when new designs are uploaded, following the engineering team's sprint cycle. Each individual event looks normal. The cadence is visible only when you analyze access patterns across 30-60 day windows.

The cadence is operationally rational. The target's data updates on a predictable schedule: board materials monthly, financial projections quarterly, engineering designs per sprint. The operator's intelligence consumer expects regular deliveries. And maintaining a consistent pattern reduces the risk of ad-hoc access at unusual times that might trigger anomaly detection. Accessing the mailbox at 09:15 every Tuesday looks like a work habit. Accessing it at 03:00 on a random Wednesday looks like a compromise. The cadence itself is a stealth mechanism.

Detecting the cadence requires a completely different approach from ransomware detection. Ransomware detection looks for events that should never happen (LSASS dumps, shadow copy deletion). Espionage detection looks for events that happen routinely but from the wrong source. The mailbox access is legitimate. The folder access is legitimate. The timestamp is during business hours. The anomaly is the device, the IP, or the application making the access. This means espionage detection depends on per-user behavioral baselines across 30-60 day windows, which are computationally expensive but essential for the cloud-native espionage pattern.

For high-value accounts (executives, finance leads, engineering directors, their assistants), the detection investment is justified. Analyze 60-day access patterns. Look for access from devices not in the user's normal device set, especially when the access targets specific folders on a regular schedule. The regularity is the signal that distinguishes espionage from opportunistic credential compromise, which is random and irregular.

Persistence mechanisms for long-term access

Espionage persistence is designed for months. The mechanisms are chosen for longevity, not speed.

OAuth consent grants with Mail.Read or Files.Read.All permissions survive password resets, session revocations, and MFA changes. The attacker registers a custom application (or abuses an existing one), obtains consent from the compromised account, and the application has persistent API access to the user's data indefinitely. The consent grant appears in Entra ID audit logs when created, but most organizations do not monitor consent events. A consent grant created four months ago for an unrecognized application with Mail.Read permissions on an executive account is exactly what espionage persistence looks like.

M365 forwarding rules to external addresses survive session revocation and password reset. The attacker creates an inbox rule that BCC's all incoming mail to an external address. The rule persists in the mailbox configuration, not in the session. Your IR team revokes the session, resets the password, enforces new MFA, and the forwarding rule continues operating because nobody checked for it.

Dormant scheduled tasks with 72-hour or weekly intervals avoid beaconing detection tuned for hourly callbacks. A task that executes a PowerShell script every Sunday at 03:00 produces one event per week, invisible to beaconing analysis using a 24-hour window.

Web shells in rarely audited application directories (/aspnet_client/, /owa/auth/, /ecp/healthcheck/) provide HTTP-based access that blends with legitimate web traffic. The shell is accessed during business hours and the HTTP requests look like normal application usage. Web shells are detectable through file integrity monitoring on web application directories, but many organizations exclude application directories from monitoring because legitimate updates modify files frequently.

The persistence mechanisms are often the most detectable artifact because establishing persistence requires a visible action (consent grant creation, forwarding rule creation, scheduled task registration) even if subsequent use is quiet. Detection should focus on the creation events, not the usage events. An OAuth consent grant creation for an unrecognized application on an executive account generates a single audit log entry on the day it is created. That one entry is your detection opportunity. If you miss it, the subsequent API access looks like legitimate application behavior for as long as the grant persists.

Remediation for espionage persistence must be comprehensive and simultaneous. Resetting the password without revoking the OAuth consent grant leaves the application's API access intact. Revoking the session without checking forwarding rules leaves the email exfiltration running. Disabling the account without auditing scheduled tasks leaves the dormant execution path active.

The IR checklist for espionage remediation is longer than for ransomware because the persistence mechanisms are more diverse and more durable. A ransomware remediation focuses on reimaging endpoints, rotating domain admin credentials, and restoring from backup. An espionage remediation must also audit every OAuth consent grant across all affected accounts, remove every inbox forwarding rule, revoke every refresh token, disable every unrecognized scheduled task, scan web application directories for shells, and verify that no new persistence was established during the remediation itself. If the attacker is monitoring the compromised account and observes the password reset, they may race to establish a new persistence mechanism in the window between the password change and the full remediation.

The order of operations matters. Revoke OAuth grants first (this cuts the API access immediately). Then revoke all sessions and refresh tokens. Then reset the password. Then check for forwarding rules, scheduled tasks, and web shells. If you reset the password first, the attacker gets an alert that their access is compromised and has time to establish new persistence before you complete the remaining steps.

ESPIONAGE CAMPAIGN — Northgate Engineering (122-day dwell)
Day 1          AiTM phishing captures session token for p.sharma
               (engineering director's assistant)
Day 1          OAuth app "Productivity Analytics" consent granted
               Permissions: Mail.Read, Files.Read.All, Calendars.Read
Day 3          First collection: MailItemsAccessed on r.okafor (CISO)
               Folders: Inbox, "Board Materials", "Incident Reports"
Day 3-120      Collection cadence: Tue+Thu 09:15-10:20 via Graph API
               No endpoint contact. No malware. No EDR alert.
Day 12         FileAccessed: Engineering/drawings/turbine-blade-v4.dwg
Day 33         FileAccessed: Engineering/proposals/MoD-contract-response.docx
Day 67         FileAccessed: Finance/board-packs/Q2-strategy-review.pptx
Day 89         FileAccessed: HR/restructuring/department-reorganization.xlsx
Day 122        Discovered during routine OAuth app audit — not by alert
Detection opportunities: Day 1 (consent grant creation in audit log),
Day 3+ (cadence analysis across 30-60 day windows),
Day 1-122 (device mismatch — unregistered device accessing exec mailbox)

Supply chain: weaponizing trust

Supply chain attacks compromise your trusted software's update mechanism. Every downstream customer receives the payload through the channel they are designed not to question. The effort-to-impact ratio explains why state-sponsored actors invest months in the positioning phase.

The positioning phase is itself an espionage campaign. The attacker must compromise the software vendor's development environment, understand the build process, identify the injection point where malicious code can be inserted without breaking the build or being caught by the vendor's code review, and ensure the modified binary passes the vendor's testing and signing processes. This positioning can take months of quiet operations inside the vendor's infrastructure.

The SolarWinds SUNBURST timeline illustrates the pattern. The attackers compromised SolarWinds' build environment in early 2020. They spent months understanding the Orion build process: where the source code lived, how builds were compiled, how updates were signed and distributed. They injected code that only activated after a 12-14 day dormancy period, only if the host domain was not a security vendor's lab environment, and only if specific security tools were not running. Approximately 18,000 customers installed the compromised update. The attackers activated operations in fewer than 100. The selection criteria (government agencies, defense contractors, cybersecurity firms) revealed the intelligence objective.

The 3CX supply chain attack in March 2023 followed a similar pattern. The attackers compromised the 3CX build pipeline and distributed a trojanized desktop client through the legitimate auto-update mechanism. Approximately 600,000 organizations used 3CX software. Customer EDR tools flagged the anomalous behavior, but many organizations suppressed the alerts because the flagged process was a trusted, vendor-signed application. This is the core supply chain detection challenge: the correct detection fired, and the defenders overrode it because they trusted the vendor more than they trusted their own detection.

Detection of supply chain compromises cannot rely on signatures, because the payload arrives inside trusted, signed software. The binary hash matches the vendor's published hash. The certificate is valid. The update channel is legitimate. Every traditional detection mechanism is satisfied. Detection requires establishing a behavioral baseline for what the trusted software normally does (which network connections it makes, which processes it spawns, which DNS queries it generates) and alerting when the behavior deviates from the baseline. A business application that has never made outbound connections to an IP in a foreign hosting range and suddenly does so after an update warrants investigation regardless of its signature status.