Manchester Airports Group (MAG) — operator of Manchester, London Stansted, and East Midlands airports — has confirmed a data breach after the criminal group FulcrumSec leaked data allegedly belonging to 8.8 million people. The compromised data, reportedly including customer email addresses and phone numbers, was held in a third-party database, not on MAG's own infrastructure. The company has stated that airport operations, passenger safety, and aviation security systems were not affected.
That distinction matters operationally, but it does not diminish the impact. 8.8 million sets of contact details in criminal hands means 8.8 million people are now exposed to highly targeted phishing, smishing, and vishing campaigns — and the attacker vector here is one of the most consistently exploited weaknesses in enterprise security: data entrusted to a third party with weaker controls than your own.
This is a textbook supply-chain data breach. No zero-day, no exotic malware — just a vendor database holding customer PII that an extortion group was able to access, exfiltrate, and leak. For defenders, the lesson is twofold: (1) you must be able to detect bulk data access and exfiltration wherever your data lives, including SaaS and vendor-hosted platforms, and (2) your third-party risk management program must treat vendor-held customer data with the same rigor as data in your own data centers.
Technical Analysis
What We Know
- Threat actor: FulcrumSec, a criminal extortion/leak group
- Victim: Manchester Airports Group (MAG)
- Attack vector: Compromise of a third-party database containing MAG customer information
- Data exposed: Names/contact records including email addresses and phone numbers of approximately 8.8 million individuals
- Impact scope: Customer PII only; MAG states airport operations, OT, passenger safety, and aviation security systems were unaffected
- Status: Data has been publicly leaked — this is past the extortion-with-threat phase; the data is in circulation
No CVE is associated with this incident, and none is claimed in the reporting. Breaches of this type typically trace back to one or more of the following, all of which defenders should treat as hypotheses during any similar investigation:
- Exposed or misconfigured cloud database (publicly reachable storage bucket, database without authentication, overly permissive network ACLs)
- Stolen credentials for the third-party platform — frequently harvested via infostealer malware or phishing against vendor staff
- Excessive data retention — the vendor held far more customer records than the business relationship required, multiplying blast radius
- Weak or absent monitoring — bulk extraction of 8.8M rows generates unmistakable telemetry if anyone is watching
Attack Chain (Defender's View)
While MAG has not published forensic detail, the canonical chain for third-party database breaches follows this pattern:
- Initial access: Valid credentials (phished, leaked, or purchased) or an internet-exposed database/storage endpoint
- Discovery: Attacker enumerates available databases/tables, identifies the largest customer dataset
- Collection: Bulk query/export —
SELECT *-style dumps, cloud storage sync, or native export functions - Exfiltration: Large-volume outbound transfer to attacker-controlled infrastructure, often via HTTPS to cloud storage or file-sharing services to blend with legitimate traffic
- Impact/Extortion: Data published on a leak site, victims notified post-facto
The defensive opportunity is concentrated in the Collection and Exfiltration stages. Pulling 8.8 million records is not a stealthy act — it is a massive anomaly against any baseline of normal application behavior.
Exploitation Status
This is a confirmed, completed breach with public data release, not a theoretical vulnerability. The exposed individuals face immediate downstream risk: expect FulcrumSec's dataset to be folded into phishing kits, credential-stuffing validation lists, and smishing campaigns within days of publication.
Detection & Response
The detections below target the behaviors that define this breach class: bulk data export, anomalous egress volume, and exfiltration tooling staging. They apply whether the data lives on your own infrastructure or — as in the MAG case — in a vendor-hosted platform where you should be demanding equivalent telemetry via contract.
Sigma Rules
---
title: Bulk Compression Staging of Data for Exfiltration
id: 9f2c1a74-3b8e-4d21-a6c7-5e8f9a0b1c2d
status: experimental
description: Detects creation of large compressed archives via common archiving utilities, a frequent precursor to mass data exfiltration as seen in third-party database breaches.
references:
- https://attack.mitre.org/techniques/T1560/001/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.collection
- attack.t1560.001
logsource:
category: process_creation
product: windows
detection:
selection_img:
Image|endswith:
- '\7z.exe'
- '\7za.exe'
- '\rar.exe'
- '\winrar.exe'
selection_cli:
CommandLine|contains:
- ' a '
- ' u '
condition: selection_img and selection_cli
falsepositives:
- Scheduled backup jobs using archivers
- Software packaging by developers
level: medium
---
title: Rclone or Cloud Sync Tool Execution for Exfiltration
id: 4e7b2d93-1c5a-4f68-b9d2-7a1e3c5f8b09
status: experimental
description: Detects execution of cloud sync/exfiltration tools (rclone, MEGAcmd, etc.) commonly used to move bulk stolen data to attacker-controlled cloud storage, as in the MAG/FulcrumSec leak.
references:
- https://attack.mitre.org/techniques/T1567/002/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.exfiltration
- attack.t1567.002
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith:
- '\rclone.exe'
- '\MEGAcmd.exe'
- '\mega-cmd.exe'
- '\gdown.exe'
- '\aws.exe'
condition: selection
falsepositives:
- Sanctioned cloud backup agents (whitelist known service accounts/hosts)
level: high
---
title: Database Server Process Spawning Shell or Export Utility
id: 6d1a8e42-9f37-4b54-c2e8-3d6b0a9f4e17
status: experimental
description: Detects database service processes spawning shells or command-line export utilities, indicative of interactive attacker access and bulk data dump activity.
references:
- https://attack.mitre.org/techniques/T1005/
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.collection
- attack.t1005
- attack.execution
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\sqlservr.exe'
- '\mysqld.exe'
- '\postgres.exe'
- '\mongod.exe'
- '\oracle.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\sqlcmd.exe'
- '\bcp.exe'
- '\mysqldump.exe'
- '\pg_dump.exe'
- '\mongoexport.exe'
condition: selection_parent and selection_child
falsepositives:
- DBA maintenance scripts and ETL jobs (tune by service account and host)
level: high
KQL (Microsoft Sentinel / Defender)
// Hunt 1: Anomalous high-volume outbound transfers from database/application servers
// Baseline against your environment; threshold tuned to flag bulk exfil of large datasets
let lookback = 14d;
let short_window = 1d;
let baseline = DeviceNetworkEvents
| where TimeGenerated between (ago(lookback) .. ago(short_window))
| where DeviceName has_any ("sql", "db", "mysql", "postgres", "mongo")
| summarize AvgDailyBytes = avg(tolong(1)) by DeviceName; // placeholder for volume-enriched sources
DeviceNetworkEvents
| where TimeGenerated > ago(short_window)
| where RemoteIPType == "Public"
| where DeviceName has_any ("sql", "db", "mysql", "postgres", "mongo")
| summarize Connections = count(), DistinctDestinations = dcount(RemoteIP), Destinations = make_set(RemoteUrl, 20) by DeviceName, InitiatingProcessFileName
| where DistinctDestinations <= 3 and Connections > 500
| sort by Connections desc;
// Hunt 2: Cloud storage / file-sharing destinations contacted by servers (exfil staging)
DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| where RemoteUrl has_any ("mega.nz", "mega.co.nz", "anonfiles", "gofile.io", "transfer.sh",
"file.io", "wetransfer.com", "temp.sh", "bashupload", "rclone")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
RemoteUrl, RemoteIP, RemotePort
| sort by TimeGenerated desc;
// Hunt 3: Mass data export tooling execution (Defender process telemetry)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName in~ ("rclone.exe", "mysqldump.exe", "pg_dump.exe", "mongoexport.exe", "bcp.exe")
or ProcessCommandLine has_any ("SELECT *", "pg_dump", "mysqldump", "mongoexport", "rclone copy", "rclone sync")
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName
| sort by TimeGenerated desc;
For SaaS and vendor-hosted databases — the actual MAG scenario — the equivalent hunts belong in Microsoft 365 / Entra ID audit logs and cloud provider logs: watch for anomalous OAuth app consent, service principal sign-ins from new geographies/ASNs, and bulk read/export operations in your cloud activity logs (CloudTrail, Azure Activity Log, GCP Audit Logs).
Velociraptor VQL
-- Hunt endpoints and servers for exfiltration staging artifacts:
-- recently created large archives and known exfil/sync tool binaries
LET archives = SELECT FullPath, Size, Mtime
FROM glob(globs=['C:/Users/*/**.zip', 'C:/Users/*/**.7z', 'C:/Users/*/**.rar',
'C:/Temp/**.zip', 'C:/Temp/**.7z',
'C:/ProgramData/**.zip', 'C:/ProgramData/**.7z'])
WHERE Size > 104857600 -- >100MB archives
AND Mtime > timestamp(epoch=now() - 604800) -- created in last 7 days
LET tools = SELECT FullPath, Size, Mtime
FROM glob(globs=['C:/Users/*/Downloads/rclone*.exe', 'C:/Users/*/**/rclone.exe',
'C:/ProgramData/**/rclone.exe', 'C:/Temp/**/rclone.exe',
'C:/Users/*/Downloads/MEGAcmd*.exe'])
SELECT 'LargeArchive' AS ArtifactType, FullPath, Size, Mtime FROM archives
UNION ALL
SELECT 'ExfilTool' AS ArtifactType, FullPath, Size, Mtime FROM tools
Remediation / Hardening Script
The following PowerShell audits a Windows/SQL environment for the exact exposure conditions behind breaches like this: database services listening on public interfaces, archiving/exfil tooling present on servers, and DLP-relevant audit policy gaps.
# MAG-Style Third-Party Database Breach: Exposure & Exfil Audit
# Run elevated on database/application servers. Read-only audit; no changes made.
Write-Host "=== [1] Database services listening on non-loopback interfaces ===" -ForegroundColor Cyan
$dbPorts = @(1433, 3306, 5432, 27017, 1521, 6379, 9200)
foreach ($port in $dbPorts) {
$listeners = Get-NetTCPConnection -LocalPort $port -State Listen -ErrorAction SilentlyContinue |
Where-Object { $_.LocalAddress -notin @('127.0.0.1','::1') }
if ($listeners) {
$listeners | ForEach-Object {
Write-Warning "EXPOSED: Port $port listening on $($_.LocalAddress) — verify firewall segmentation"
}
}
}
Write-Host "`n=== [2] Exfiltration/sync tooling present on this host ===" -ForegroundColor Cyan
$toolPaths = @("$env:ProgramData", "$env:SystemDrive\Users", "$env:SystemDrive\Temp")
$tools = @('rclone.exe','MEGAcmd.exe','mega-cmd.exe','gdown.exe','winscp.exe','filezilla.exe')
foreach ($base in $toolPaths) {
if (Test-Path $base) {
Get-ChildItem -Path $base -Recurse -Include $tools -ErrorAction SilentlyContinue |
Select-Object -First 25 |
ForEach-Object { Write-Warning "FOUND: $($_.FullName) — investigate legitimacy" }
}
}
Write-Host "`n=== [3] Firewall rules permitting database ports from broad scopes ===" -ForegroundColor Cyan
Get-NetFirewallRule -Enabled True -Direction Inbound -ErrorAction SilentlyContinue |
Where-Object { $_.Profile -match 'Public|Any' } |
ForEach-Object {
$rule = $_
$ports = ($_ | Get-NetFirewallPortFilter -ErrorAction SilentlyContinue).LocalPort
if ($ports | Where-Object { $_ -in $dbPorts }) {
Write-Warning "REVIEW: Rule '$($rule.DisplayName)' allows inbound DB port(s) on Public/Any profile"
}
}
Write-Host "`n=== [4] Audit policy for sensitive object access ===" -ForegroundColor Cyan
$audit = auditpol /get /subcategory:"File System" 2>$null
if ($audit -notmatch 'Success and Failure') {
Write-Warning "File System auditing not fully enabled — bulk data access may go unlogged"
}
Write-Host "`nAudit complete. Remediate exposures, then repeat on all systems hosting customer data." -ForegroundColor Green
Remediation
For Organizations Holding Customer Data (Including via Third Parties)
- Inventory your data egress points immediately. You cannot detect exfiltration from a database you forgot exists. Build a complete register of every system — internal and vendor-hosted — that stores customer PII, with data classification, record counts, and access paths.
- Enforce third-party contractual security requirements: right-to-audit clauses, mandatory breach notification SLAs (24–72 hours), minimum logging/monitoring standards, data retention limits, and evidence of controls (SOC 2 Type II, ISO 27001). MAG's breach happened on vendor infrastructure — your contracts are your only control plane there.
- Minimize vendor-held data. If a marketing database at a third party held 8.8M customer records, ask why. Share only what the business function requires, pseudonymize where possible, and enforce deletion schedules.
- Baseline and alert on bulk export behavior for every customer-data store: query volume, row counts, export API calls, and egress bytes per destination. A multi-million-row extraction should page someone.
- Block unsanctioned cloud storage and sync tools at the proxy/EDR level (rclone, MEGA, etc.) and alert on their execution from server estates.
- Segment databases from the internet. No customer database should be reachable from a public interface; require VPN/PrivateLink plus MFA-backed access with just-in-time elevation.
For MAG-Scale Incident Response
- Activate your third-party breach playbook: preserve vendor logs (authentication, query, export, egress), obtain the vendor's forensic timeline, and validate the leaked dataset's authenticity and exact field scope.
- Regulatory notification: UK GDPR applies — ICO notification within 72 hours of awareness where risk to individuals exists, and direct notification to affected individuals given the phishing risk profile of email/phone data.
- Customer harm reduction: proactive warnings about MAG-themed phishing/smishing, standing up takedown requests for impersonation domains, and monitoring for credential-stuffing against MAG customer portals (password reuse is endemic).
- Demand-side monitoring: track criminal forums and leak-site reposts for dataset redistribution; engage takedown services where legally viable.
For Potentially Affected Individuals (Guidance to Publish to Customers)
- Treat unsolicited emails/texts/calls referencing MAG, Manchester, Stansted, or East Midlands airports as hostile until verified
- Never click links in breach-notification emails — navigate to official sites directly
- Enable MFA on email accounts; the leaked emails are now phishing targets with confirmed validity
Related Resources
Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.