HTB CPTS study materials
HTB CPTS study resources

Leaked Credentials and the Lockout Budget

HTB CPTS · Put your knowledge to work in context.

All case studies

Leaked Credentials and the Lockout Budget

Blackmere Health hires you for a two-week external assessment. The RoE permits passive OSINT and limited authentication testing against vpn.blackmere-health.com, with a lockout threshold of five failed attempts per 30 minutes per account, and explicitly forbids password spraying. During OSINT you find: (a) a public GitHub repo under a developer's personal account with a committed .env containing DB_HOST=10.20.30.15, DB_USER=svc_report, and password 'Summer2023!'; (b) an employee Instagram post showing a badge barcode; (c) certificate transparency logs listing 37 subdomains, including jenkins.blackmere-health.com; (d) a Pastebin dump claiming to be Blackmere credentials. You have three days and no active scanning authorization beyond the VPN portal. The client wants 'proof that leaked credentials are a real risk.' The SOC will alert on more than 10 authentication failures per hour from one IP.

1. Rank the four OSINT findings by evidential value and risk, and state what you would validate.

Read the worked answer

CT logs first. They are passive, cheap, and reveal a real asset (jenkins.blackmere-health.com). That is exposure evidence and may justify a scope request, but Jenkins authentication is not authorized, so I would not test it.

GitHub second. This is actual credential material. I would confirm whether the repo is public, record the commit hash and timestamps, and preserve a screenshot. Then I would make one authentication attempt with svc_report against the VPN. One attempt is below the five-per-30-minute lockout and far below the SOC alert threshold. If it fails, I stop; I do not retry, vary the password, or spray.

Pastebin third. Unverified and possibly old or planted. I would not test it and would label it low confidence.

Badge photo fourth. It is PII and a physical-security risk, not a credential. I would not use or retain it.

The validation goal is 'is the leaked secret live?' not 'how many accounts can I try.'

2. How do you handle the badge photo and the Instagram post?

Read the worked answer

I would not download, crop, enhance, or retain the badge image. It contains personal data and could enable physical access, which is outside the RoE and creates legal and ethical risk. I would note in the report that an employee publicly exposed a badge barcode, describe the risk in general terms, and recommend a badge-photo and social-media policy. I would not interact with the employee, attempt to decode the barcode, or use it for social engineering. For the Instagram post, I would record only the fact that it exists and the date, not the person's identity or image. If the client needs evidence, I would offer a description and a reference to the public post rather than reproducing the content. Data minimization applies even when the data is public.

3. The client asks you to test 10.20.30.15 with the leaked database password. What do you say?

Read the worked answer

10.20.30.15 is not in scope. A password in a public repo is a finding, not authorization to connect to a production database. Connecting could modify data, fill logs, trigger locks, or cause an outage. I would request a written scope expansion that names the host, the allowed source IP, read-only query limits, a testing window, and an emergency contact. If approved, I would connect from a controlled host, run only read-only metadata queries, and avoid touching tenant data. If not approved, I would report the leak, recommend immediate rotation of svc_report, and note that the database may be reachable from the internet or from the VPN. The client can validate internally with their own DBA, which is often faster and safer.