No external path, two days left: a public gist and a marketing subdomain

Sequence by risk, not by excitement.

1. The CMS (first, today). Default admin on a marketing CMS is a zero-availability-risk path: no lockout policy to trip, no production dependency, and it is in scope by name. Log in, capture the version, enumerate what the admin account can do (upload, template edit, plugins), and check whether the CMS can reach anything internal. If admin upload yields web shell, that is a solid external foothold - prove execution with a benign marker, then stop.

2. The leaked credential (second, tomorrow morning). It is authorised in writing: public-domain credential, in-scope asset. Justification for using it is straightforward - an attacker reading GitHub would try exactly this, and the client's stated objective is to know whether an internet attacker reaches customer data. The gist has been public for 14 months, so the exposure is real whether or not you test it.

Controls before the first login attempt:

• Check the lockout policy first (ask the sponsor; trip three failed attempts and you may lock the real backup service account).
• Prefer a single successful authentication to an in-scope endpoint over password spraying.
• Use one designated source IP registered with the client, and inform the security operations contact in the engagement channel immediately before and after, so a genuine intrusion alert is not raised against your own traffic.
• Do not touch the core banking system; the change freeze starts in 48 hours and you are not going to be the reason a bank freezes.

Why not the credential first: if it fails or locks, you have burned availability on a live service and gained nothing. Cheapest, lowest-risk path first is the same discipline an attacker uses - it just happens to also be the professional one.

Prove reachability and access rights; do not open customer records.

On backup01, in order:

• whoami /priv and whoami /groups - a backup service account frequently holds SeBackupPrivilege or is a local administrator, which raises severity far more than any file listing.
• Enumerate what the account can see: backup catalogue, job schedules, share names, and the retention path. A directory listing of a backup share is evidence; opening a backup file is not necessary.
• If you need to prove read access, read a file whose contents are non-sensitive (a backup log, a manifest) and confirm the service account's read permission on the customer database backup by ACL inspection (icacls) rather than by reading it.
• Prove the path onward by network reachability: port scan from backup01 to the core banking segment to show whether an attacker with this foothold could reach the database tier. Reachability is a finding; exploitation of the core banking system is a separate authorisation you do not have.

What I explicitly avoid: mounting or restoring a backup, copying a database file, or running a query against production. Restores are the single most disruptive action available on a backup server and would breach the "do not affect" expectation without adding evidence value.

Framing the finding: "Internet attacker with a public credential obtained backup-server access, which provides read access to customer database backups and network reach to the core banking segment." That sentence, evidenced by privilege listing plus ACL plus reachability, is more persuasive to a board than a stolen table, and it does not create a reportable data incident for the client. If the client wants the data-access proof for their auditors, that is their call, done by their DBA, in their window, under their change control.

This stops being a penetration test finding and becomes a suspected incident. The distinction matters because the obligations, the audience, and the evidence handling all change.

Next hour:

1. Preserve evidence - capture the gist URL, author, commit timestamps, full text, and hashes; screenshot with a timestamp. Do not edit, comment on, fork, or otherwise interact with the gist. Do not download with a personal account.
2. Notify the engagement sponsor and the security operations lead in writing, at whatever escalation level the contract specifies for critical findings - this is the one category that does not wait for the final report. Copy legal or the data protection officer if the contract names them.
3. Stop using the credential once its validity is confirmed. Continued authentication after notification muddies an investigation and could destroy log evidence the IR team needs.
4. Ask the questions a tester cannot answer: is svc_backup still active? Are there anomalous logins in the last 14 months? Is the contractor still engaged, and under what access? Those require the client's identity and HR processes, not yours.
5. Recommend immediate rotation of the credential and a review of any other secrets in that contractor's public footprint - a leaked backup password is rarely the only one.

Reporting implications: put this in a separate, restricted-distribution section titled "suspected credential exposure", with a timeline, not in the standard findings table. It is an indicator of possible compromise, and the client may need to notify a regulator depending on what the logs show.

And keep testing what is authorised - the CMS work continues. But if the logs suggest the account was already used by a third party, the engagement should pause that thread and support the incident response; a retest report is worthless if the tester trampled the evidence trail.