Back to Intelligence

Scottish Government COPFS Breach via Third-Party Supplier: Detection and Supply-Chain Defense Guide

SA
Security Arsenal Team
August 15, 2026
10 min read

Scotland's Crown Office and Procurator Fiscal Service (COPFS) — the agency responsible for prosecuting crime across Scotland — has disclosed a data breach that did not originate inside its own network. The intrusion traces back to a third-party supplier, and early reporting indicates that same supplier may have provided services to other Scottish government agencies. That detail matters: this is not a single-victim incident, it is a potentially widening supply-chain event where the blast radius is still being mapped.

I have led IR engagements on exactly this pattern. When a shared supplier is compromised, the initial disclosure is almost never the final victim count. Prosecution service data is among the most sensitive a government holds — witness identities, case files, evidence chain-of-custody records, and in some cases personal data of victims and informants. If that data traverses a vendor's systems, the vendor's security posture effectively becomes your security posture.

Defenders — especially those in government, legal, healthcare, and any sector relying on managed service providers, IT suppliers, or SaaS processors — need to treat this as a live case study. The questions you should be asking today: which of my suppliers can reach my data, what can they see, and would I even detect it if one of them were compromised?

Technical Analysis

What We Know

Based on the public reporting:

  • Victim: Crown Office and Procurator Fiscal Service (COPFS), a Scottish Government agency.
  • Vector: A third-party supplier — the breach did not originate from a direct attack on COPFS infrastructure.
  • Scope concern: The supplier may have serviced other Scottish government agencies, raising the possibility of a multi-agency compromise from a single upstream intrusion.
  • CVE status: No CVE has been associated with this incident. This is a supplier-compromise scenario, not (as of disclosure) a publicly identified software vulnerability. Do not wait for a CVE to act — third-party breaches frequently never receive one.

The Attack Pattern (From a Defender's Perspective)

While specific TTPs have not been publicly confirmed, supplier-borne breaches against government entities consistently follow one of a small set of patterns:

  1. Vendor credential compromise. The supplier holds credentials, VPN access, API keys, or service accounts that reach into client environments or client-hosted data. Attackers phish, password-spray, or infostealer-harvest those credentials and ride the trusted path in.
  2. Vendor-side data aggregation. The supplier hosts or processes client data on its own infrastructure (case management SaaS, document handling, IT support tooling). Breaching the vendor exposes every client's data at once — the classic aggregation-of-risk problem.
  3. Abuse of remote management / support tooling. RMM platforms, helpdesk remote access, and managed file transfer (MFT) integrations give suppliers persistent, often privileged, connectivity. MFT exploitation has been the single most damaging vector in this class in recent years.
  4. OAuth / application consent abuse. A vendor-integrated application with broad mailbox or file permissions is hijacked, giving attackers API-level access that bypasses interactive authentication controls entirely.

The common thread: the trust relationship is the attack surface. Your perimeter controls, EDR coverage, and MFA policies mean little if a supplier's less-controlled environment holds keys to yours.

Why This Is a Widening Event

When a supplier services multiple agencies, defenders should assume:

  • Attackers who established persistence in the vendor environment likely enumerated the vendor's full client list and connection inventory.
  • Credentials or tokens for other agencies may already be in attacker hands even if only one agency has disclosed.
  • Lateral movement from vendor tooling into additional client tenants can occur weeks or months after initial vendor compromise.

If your organization shares suppliers with COPFS or with other Scottish public-sector bodies, you are in the potential blast radius right now — not after a formal notification letter arrives.

Detection & Response

The detections below target the observable behaviors common to supplier-compromise intrusions: anomalous third-party account activity, mass data access against case/document repositories, and bulk staging or exfiltration. They are deliberately behavior-focused rather than indicator-focused, because no public IOC set exists for this incident yet.

YAML
---
title: Third-Party or Vendor Account Anomalous Data Access
description: Detects service accounts or named vendor accounts performing bulk file access, archive creation, or access from unusual sources — consistent with supplier credential abuse leading to data theft.
logsource:
  product: windows
  category: process_creation
detection:
  selection_archive_tools:
    Image|endswith:
      - '\7z.exe'
      - '\rar.exe'
      - '\winzip.exe'
      - '\tar.exe'
    CommandLine|contains:
      - ' a '
      - ' -p'
      - '.zip'
      - '.7z'
      - '.rar'
  selection_user_context:
    User|contains:
      - 'svc_'
      - 'svc-'
      - 'vendor'
      - 'msp'
      - 'support'
  condition: selection_archive_tools and selection_user_context
falsepositives:
  - Scheduled vendor backup jobs — baseline and whitelist known maintenance windows and job names
level: high
status: experimental
author: Security Arsenal
date: 2026/01/15
references:
  - https://attack.mitre.org/techniques/T1560/
  - https://attack.mitre.org/techniques/T1078/
tags:
  - attack.collection
  - attack.t1560.001
  - attack.t1078
id: 3f9c2a71-8b4d-4e6a-9c1f-2d5e7a8b9c01
---
title: Mass File Access from Non-Standard Process
description: Detects non-productivity processes reading large volumes of files from document shares or case-management directories — a hallmark of vendor-tooling abuse for bulk collection.
logsource:
  product: windows
  category: file_event
detection:
  selection_paths:
    TargetFilename|contains:
      - '\casefiles\'
      - '\casework\'
      - '\legal\'
      - '\evidence\'
      - '\shared\documents\'
  selection_suspicious_image:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\cmd.exe'
      - '\rclone.exe'
      - '\curl.exe'
      - '\wscript.exe'
  condition: selection_paths and selection_suspicious_image
falsepositives:
  - Legitimate document migration tooling — verify against change records
level: medium
status: experimental
author: Security Arsenal
date: 2026/01/15
references:
  - https://attack.mitre.org/techniques/T1219/
  - https://attack.mitre.org/techniques/T1567/
tags:
  - attack.collection
  - attack.exfiltration
  - attack.t1567
id: 7b1e4d92-3c5f-4a8b-b2d6-9e0f1a3c5d72
---
title: OAuth Application Granted Broad Mail or File Permissions
description: Detects consent grants giving an application Mail.Read, Files.Read.All, or full_access scopes — a common vendor-integration abuse vector in supply-chain intrusions.
logsource:
  product: azure
  service: auditlogs
detection:
  selection_operation:
    OperationName:
      - 'Consent to application'
      - 'Add service principal'
      - 'Add app role assignment to service principal'
  selection_scope:
    TargetResources|contains:
      - 'Mail.Read'
      - 'Files.Read.All'
      - 'full_access_as_app'
      - 'Sites.Read.All'
      - 'Directory.Read.All'
  condition: selection_operation and selection_scope
falsepositives:
  - Approved enterprise application onboarding — maintain a vetted app allowlist and alert on anything outside it
level: high
status: experimental
author: Security Arsenal
date: 2026/01/15
references:
  - https://attack.mitre.org/techniques/T1528/
  - https://attack.mitre.org/techniques/T1550/
tags:
  - attack.persistence
  - attack.credential_access
  - attack.t1528
id: c4a8f1e6-2d7b-49c3-a5e1-8f3b6d0a2e94
KQL — Microsoft Sentinel / Defender
// Hunt: anomalous third-party / service account activity consistent with supplier compromise
// Looks for vendor-pattern accounts with unusual logon sources, off-hours activity,
// and bulk data access — run across a 14-day window and compare against your baseline.
let lookback = 14d;
let vendor_accounts = dynamic(["svc_", "svc-", "vendor", "msp", "support", "helpdesk"]);
let baseline = SecurityEvent
    | where TimeGenerated between (ago(90d) .. ago(lookback))
    | where EventID == 4624
    | where Account has_any (vendor_accounts)
    | summarize KnownIPs = make_set(IpAddress) by Account;
SecurityEvent
| where TimeGenerated > ago(lookback)
| where EventID == 4624
| where Account has_any (vendor_accounts)
| where LogonType in (3, 10)  // network and remote interactive — typical vendor access paths
| join kind=leftanti (baseline) on Account, $left.IpAddress == $right.KnownIPs
| extend HourOfDay = datetime_part("hour", TimeGenerated)
| extend OffHours = HourOfDay < 6 or HourOfDay > 22
| summarize FirstSeen = min(TimeGenerated),
            LogonCount = count(),
            DistinctSources = dcount(IpAddress),
            SourceIPs = make_set(IpAddress),
            TargetSystems = make_set(Computer),
            AnyOffHours = max(OffHours)
    by Account, bin(TimeGenerated, 1d)
| where DistinctSources > 1 or AnyOffHours == 1 or LogonCount > 50
| sort by LogonCount desc;
KQL — Microsoft Sentinel / Defender
// Companion hunt: bulk file reads against sensitive shares followed by egress,
// surfaced via Defender for Endpoint telemetry
let sensitive_paths = dynamic(["casefile", "casework", "evidence", "legal", "witness"]);
DeviceFileEvents
| where TimeGenerated > ago(7d)
| where FolderPath has_any (sensitive_paths)
| where ActionType in ("FileCreated", "FileModified", "FileRenamed")
| summarize FileOps = count(), DistinctFiles = dcount(FileName), Processes = make_set(InitiatingProcessFileName)
    by DeviceName, InitiatingProcessAccountName, bin(TimeGenerated, 1h)
| where FileOps > 200
| join kind=inner (
    DeviceNetworkEvents
    | where TimeGenerated > ago(7d)
    | where RemoteIPType == "Public"
    | summarize EgressConnections = count(), RemoteDestinations = make_set(RemoteUrl)
        by DeviceName, InitiatingProcessAccountName, bin(TimeGenerated, 1h)
) on DeviceName, InitiatingProcessAccountName, TimeGenerated
| project TimeGenerated, DeviceName, InitiatingProcessAccountName, FileOps, DistinctFiles, Processes, EgressConnections, RemoteDestinations;
VQL — Velociraptor
-- Hunt for archive staging and compression artifacts left by bulk collection
-- Run across endpoints and servers that host shared or case-management data
SELECT FullPath,
       Size,
       Mtime,
       Ctime,
       hash(path=FullPath) AS FileHash
FROM glob(globs=[
    'C:\\Users\\**\\*.7z',
    'C:\\Users\\**\\*.rar',
    'C:\\ProgramData\\**\\*.zip',
    'C:\\Windows\\Temp\\**\\*.zip',
    'C:\\Windows\\Temp\\**\\*.7z'
])
WHERE Mtime > (now() - 1209600)  -- last 14 days
  AND Size > 10000000            -- >10MB archives are the interesting ones
ORDER BY Mtime DESC
PowerShell
# Third-party access audit and containment — run on domain controllers / management hosts
# 1) Inventory service and vendor-pattern accounts and their last logons
Get-ADUser -Filter {Name -like "svc_*" -or Name -like "*vendor*" -or Name -like "*msp*" -or Name -like "*support*"} `
  -Properties LastLogonDate, PasswordLastSet, MemberOf, Enabled |
  Select-Object Name, SamAccountName, Enabled, LastLogonDate, PasswordLastSet,
    @{N='Groups';E={($_.MemberOf | Get-ADGroup | Select-Object -ExpandProperty Name) -join '; '}} |
  Export-Csv -Path ".\third_party_account_inventory.csv" -NoTypeInformation

# 2) Flag vendor accounts with excessive privilege for immediate review
$PrivilegedGroups = @("Domain Admins","Enterprise Admins","Administrators","Backup Operators")
foreach ($g in $PrivilegedGroups) {
  Get-ADGroupMember -Identity $g -Recursive -ErrorAction SilentlyContinue |
    Where-Object {$_.SamAccountName -match 'svc_|vendor|msp|support'} |
    ForEach-Object { Write-Warning "$($_.SamAccountName) is a member of $g — review immediately" }
}

# 3) Review Azure AD / Entra app consents for over-scoped vendor integrations
Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All" -NoWelcome
Get-MgServicePrincipal -All | ForEach-Object {
  $sp = $_
  Get-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId $sp.Id -All -ErrorAction SilentlyContinue |
    Where-Object {$_.Scope -match 'Mail.Read|Files.Read.All|Sites.Read.All|full_access'} |
    Select-Object @{N='AppName';E={$sp.DisplayName}}, @{N='AppId';E={$sp.AppId}}, Scope, ConsentType
} | Export-Csv -Path ".\broad_oauth_consents.csv" -NoTypeInformation

# 4) Emergency lever: disable a confirmed-compromised vendor account (uncomment when authorized)
# Disable-ADAccount -Identity "svc_vendoraccount"
# Revoke-MgSignInSession -UserId "vendoraccount@yourdomain.tld"

Remediation

If your organization is a confirmed or suspected victim — or shares suppliers with a victim — execute in this order:

  1. Activate IR and legal immediately. Public-sector prosecution data triggers statutory notification duties (UK GDPR / DPA 2018 in this context; HIPAA or state breach statutes for US healthcare and legal entities). Engage counsel before broad internal communications. The ICO notification clock is 72 hours from awareness for UK GDPR.

  2. Demand specifics from the supplier — in writing. What systems, what data classes, what date range of access, what other clients are affected, and what is their forensic status. A vague "we experienced an incident" letter is not an answer; it is the start of the conversation.

  3. Rotate every credential the supplier touched. Service accounts, API keys, VPN credentials, certificates, SAS tokens, OAuth client secrets. Assume all are compromised until the vendor's forensics prove otherwise. Prioritize anything with privileged or data-plane access.

  4. Constrain the vendor's access path now. If the supplier connects via VPN, RMM, or site-to-site tunnel, scope it down to the minimum ports, hosts, and accounts required — or suspend it entirely until clearance. Log and alert on all vendor-sourced traffic as a distinct category.

  5. Audit OAuth and application consents. Pull the consent inventory (script above). Revoke any grant you cannot tie to a documented, approved business need. Broad scopes like Mail.Read or Files.Read.All held by third-party apps are pre-positioned exfiltration channels.

  6. Hunt backward, not just forward. Review 90+ days of vendor account authentication, data access, and egress. Supplier compromises are routinely discovered months after initial access. The detections above are built for exactly this retrospective hunting.

  7. Map your own aggregation risk. Identify which of your suppliers hold multi-client data or broad access. Require incident notification SLAs (24-48 hours), evidence of independent security assessment, and least-privilege access in contracts. If a supplier cannot tell you within a day whether you were affected by their breach, that supplier is a liability.

  8. Brief other potentially affected parties. In a shared-supplier scenario, peer agencies and clients benefit from early informal warning. Sector ISACs and — for UK public sector — the NCSC are appropriate coordination channels.

The hard lesson from every supplier-breach engagement I have worked: the time to build third-party visibility is before the breach notification arrives. If you cannot answer "what can this vendor see and do in my environment" in under an hour, close that gap this quarter — because your suppliers' attackers are already counting on it.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.