OSINT Scoping for a Pre-Engagement Red Team
Northwind Logistics, a 1,200-employee freight company, has asked for a five-day OSINT-only assessment before a red team engagement. Scope: three primary domains (northwindlogistics.com, nwl-freight.com, northwind-coldchain.com), 14 subsidiary brands, and public GitHub/LinkedIn presence. You are told not to touch any live systems; no port scanning, no DNS brute force, no contact with employees. The client wants a list of likely phishing targets and any exposed credentials that could be used in the later engagement. During collection you find a 2023 pastebin dump claiming to contain 400 Northwind email/password pairs, a GitHub repo under a subsidiary with a committed .env file, and a recruiter’s LinkedIn post listing internal tool names. The engagement lead asks you to prioritize findings for the red team and to avoid reporting unverified breach claims. You have 10 hours of analyst time.
1. How do you triage and validate the three OSINT findings before including them in the red-team handoff? Explain the order and the evidence threshold for each.
Read the worked answer
Order by actionability and risk of false positive: (1) committed .env in GitHub, (2) pastebin credential claim, (3) LinkedIn tool names.
.env: treat as highest because a secret in a public repo is direct evidence. Verify repo ownership (org affiliation, commit author domain), commit date, whether the file is still reachable, and secret type. Do not make live API calls if rules prohibit them. Evidence threshold: public URL, commit hash, redacted key preview, and a note on whether the secret appears active. If active, notify the client immediately via secure channel.
Pastebin: do not test credentials. Validate that the domain and naming convention match Northwind, sample a few entries without exposing passwords, check dump date and whether addresses are role-based or personal. Evidence threshold: at least 20% of sampled emails resolve to known Northwind formats and the dump is not obviously recycled. Report as 'third-party claim, unverified' unless corroborated by a second source.
LinkedIn: lowest risk but useful for targeting. Map tool names to internal systems and identify roles with access. Evidence threshold: at least two independent public references (post plus job ad) before asserting a tool is in use.
Handoff should label each finding as confirmed, likely, or unverified, with source URLs and collection timestamps.
2. The client’s marketing team asks you to include the 400 leaked credentials in the final OSINT report as a 'confirmed breach.' What is your response and what wording do you use?
Read the worked answer
I would push back on 'confirmed breach' because OSINT collection cannot confirm that the credentials are valid, current, or tied to Northwind systems. The pastebin only claims they are. Confirmation would require authentication testing, which is out of scope and could lock accounts. I would explain that overstating the finding creates legal and reputational risk for the client and undermines the red team's trust in our data.
Wording: 'A third-party pastebin post dated 2023 claims to contain 400 email/password pairs associated with Northwind. We did not test these credentials. Sampling showed that 84 of 100 addresses matched Northwind's email naming pattern, but validity and currency are unverified. We recommend forcing password resets for the affected accounts and reviewing MFA coverage. Treat this as a lead for the red team, not a confirmed compromise.'
If marketing insists, I would escalate to the engagement lead and document the disagreement. The report can include the claim as an 'unverified exposure' with a clear evidence table, but not as confirmed.
3. The GitHub .env file contains an AWS access key that appears active. The engagement rules prohibit any cloud API calls. What do you do next, and what do you not do?
Read the worked answer
Do not call AWS APIs, do not use the key, and do not attempt to validate permissions. The rules prohibit it, and even a benign call could create logs in the client's CloudTrail or trigger alarms. Instead: (1) capture the public evidence: repo URL, commit hash, file path, key prefix and last four characters only, commit author, and timestamp; (2) classify the finding as potentially critical because a live cloud key can lead to data exposure; (3) notify the client's designated security contact immediately through the agreed secure channel, separate from the final report; (4) recommend immediate key rotation and a review of CloudTrail for the key's use; (5) document that validation was intentionally not performed due to scope. If the client later authorizes a controlled validation, get it in writing and use a read-only call with a defined stop condition. The judgement is to prioritize containment over proof when the risk is a live secret.