I turned on secret scanning. 8.8 million people are why you should too

The thing that keeps me up isn’t the ransom note. It’s the key sitting in a config file that nobody has looked at since 2021, that still works, that grants more than anyone remembers granting. Manchester Airports Group (MAG) refused a ransom demand this week, and a threat actor answered by publishing roughly 550GB of data said to cover 8.8 million people. Refusing to pay is a defensible policy. The part worth your attention is everything that had to go wrong before the ransom conversation ever started.

550GB

That’s the size of the dump SecurityWeek reports was published after the refusal. Half a terabyte is not a smash-and-grab. It’s the signature of an attacker who had time — enough access, for long enough, to enumerate storage and pull it down without tripping anything that mattered. You don’t exfiltrate 550GB through a phishing foothold in an afternoon. You do it when you’re holding a credential that looks legitimate to every log that watches it.

Sit with the number for a second at 2 a.m., because that’s when you’ll be reading it off a leak site. 550GB is not a spreadsheet someone emailed to the wrong address. It’s the contents of buckets, backups, maybe database exports. The volume itself tells you the access was broad and the dwell time was generous.

8.8 million

The reported count of individuals in the dataset. I’m going to be careful here, and you should be too: the exact composition of those records — names, contact details, travel data, employee files, whatever mix it turns out to be — is not something I’ll assert beyond what’s confirmed. Threat actors inflate. Early reporting compresses nuance. What the 8.8 million figure does tell you is scale, and scale in the travel sector means the blast radius includes passengers who never signed up for anything except a flight, plus staff and partners who are far easier to phish once their details are in the open.

Treat any specific claim about passport numbers or payment cards as unverified until MAG or a regulator says so. The pressure to fill that gap with speculation is exactly how bad breach coverage gets written.

1 key

The reported entry point is exposed admin keys. That phrase covers a lot of sins, and the honest answer is that the precise location — a git repo, a SaaS admin panel, a hardcoded credential in a shipped app, an over-permissioned cloud access key — hasn’t been nailed down publicly at the time of writing. So let’s not pretend we know which one. What we do know is the class of failure, and it’s the most boring, most common, most preventable one there is.

Long-lived credentials are the asbestos of modern infrastructure. Cheap to install, everywhere, fine until someone disturbs them. An admin key that never expires and never rotates is a permanent skeleton key that ages into a liability the moment the person who created it leaves, or the repo goes public, or a laptop gets imaged. The attacker doesn’t need a zero-day when you’ve left a valid credential in the open. They need a search box.

Every “sophisticated nation-state actor” press release I’ve read in ten years has, on inspection, started with a credential someone left where a scanner could find it.

7 days

I turned on secret scanning across every repository I own for a week — GitHub Advanced Security on the estate that supports it, gitleaks in CI on the rest. Here’s what fell out: a decommissioned service’s storage key still valid three years after the service died, two API tokens in commit history that had been “removed” in a later commit (history remembers everything), and a personal access token with repo-wide scope pasted into a README as an “example.” None of that was exotic. All of it was live. That was one engineer’s week on one estate. Extrapolate to an organisation running an airport.

Start where the attacker starts — in your source history:

1
2
3
4
5
6
7
8
9
10
11

# Report-only scan of a repo AND its full history
# gitleaks does not modify anything; this is a read-only audit
gitleaks detect \
  --source . \
  --log-opts="--all" \
  --report-format sarif \
  --report-path gitleaks-report.sarif \
  --no-banner
​
# Second opinion with TruffleHog, verified secrets only (still read-only)
trufflehog git file://. --only-verified --json > trufflehog-report.json

--only-verified matters: TruffleHog will actually test whether a found credential still authenticates. A verified hit is not a maybe. It’s a door that’s open right now.

0 expiry

The credentials that hurt you are the ones with no expiry set. In Entra ID, that’s app registrations and service principals carrying password or certificate credentials that outlive their usefulness. Audit them with Microsoft Graph, in read-only mode, and sort by what’s already expired or never dies:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# Read-only. Requires Application.Read.All (delegated is fine for an audit)
Connect-MgGraph -Scopes "Application.Read.All" -NoWelcome
​
$apps = Get-MgApplication -All -Property "displayName,appId,passwordCredentials,keyCredentials"
​
$findings = foreach ($app in $apps) {
    foreach ($cred in @($app.PasswordCredentials + $app.KeyCredentials)) {
        [pscustomobject]@{
            App        = $app.DisplayName
            AppId      = $app.AppId
            Type       = if ($cred.Key) { "Certificate" } else { "ClientSecret" }
            EndsOn     = $cred.EndDateTime
            Expired    = $cred.EndDateTime -lt (Get-Date)
            LongLived  = ($cred.EndDateTime - $cred.StartDateTime).Days -gt 365
        }
    }
}
​
# Nothing is changed. You just get a list of what to hunt down.
$findings | Sort-Object Expired, EndsOn |
    Format-Table App, Type, EndsOn, Expired, LongLived -AutoSize

On AWS, the equivalent question is which IAM access keys are old and possibly forgotten. The credential report answers it without touching anything:

1
2
3
4
5
6
7
8

# Generates and reads the IAM credential report; no keys are rotated or deleted
aws iam generate-credential-report >/dev/null
aws iam get-credential-report \
  --query 'Content' --output text | base64 --decode \
  | awk -F',' 'NR==1 || $9=="true"' \
  | column -t -s','
# Column 9 is access_key_1_active. Cross-check access_key_1_last_rotated
# against your rotation policy. Anything older than 90 days is a question.

The order of operations

If any of the above returned a hit, do this, in this order, and don’t let a change-advisory board slow the first step:

• Immediate: Revoke and rotate any credential a scanner verified as live, starting with anything carrying admin or broad cloud scope. A found secret is a compromised secret — rotate it whether or not you think it was used.
• Immediate: Turn on push protection / pre-receive secret scanning so the next key never lands in history in the first place. Cleaning history is miserable; preventing the commit is free.
• This week: Set expiry on every long-lived cloud and app credential, and move the ones that can be moved to managed identities, workload identity federation, or short-lived STS/OBO tokens. The goal is fewer standing secrets, not better-guarded ones.
• This week: Wire secret-scanning findings into detection, and alert on the use of a leaked credential, not just its existence. Exposure and exploitation are different clocks.
• Next cycle: Enforce rotation as policy with a maximum lifetime, and audit against it on a schedule so this doesn’t decay back to where it started in eighteen months.

On the refusal itself: I won’t second-guess MAG for declining to pay. A no-pay stance is often the right long-term call, and it’s a policy far more organisations claim than have ever tested under real pressure. But the policy is a decision about the last five minutes of an incident. The credential hygiene is a decision about the six months before it. Only one of those was ever in anyone’s control.

Run the scans tonight. Not because you’ll find 8.8 million records — because you’ll find the one key that could get you there, and it’s cheaper to find it before someone else does.