OSINT Assessment Services

Open-source intelligence (OSINT) assessment examines publicly available information that could expose an organisation to risk. ProCheckUp investigates agreed targets and records the evidence supporting each relevant observation.

Agreed targets and questions

• Approved organisations, brands and other targets

• Public information relevant to the assessment question

• Evidence quality, attribution and potential exposure

From exposed information to a remediation decision

Our GitHub credential leak investigation case study shows how discovery and validation answer different questions. We reviewed approximately 800 repositories and identified more than 2,300 instances of potentially sensitive material. Selected credentials were then assessed through controlled, authorised validation to distinguish active, inactive and unverified findings.

That engagement combined repository analysis, OSINT and a separately scoped validation phase. Its results illustrate an approach to assessing exposed information; they are not a promise that every OSINT assessment includes credential testing.

Discuss an OSINT assessment with the targets, business question and boundaries you have in mind.

Example finding: an exposed email-service credential

This anonymised summary is based on our published GitHub case study. It is not a client report extract; identifiers and secret values are intentionally omitted.

• Evidence: a credential was identified during the repository review. Authorised validation confirmed that a SendGrid key was active and had extensive administrative permissions.

• Confidence and limits: the credential's validity and permissions were confirmed in that engagement. This does not establish that a malicious party used it. Testing stopped after authentication was confirmed.

• Risk: the exposed permissions created a potential route to misuse of the email service. Assessing actual misuse requires the customer's service logs and further investigation.

• Recommended action: revoke or rotate the exposed credential, review relevant audit and service logs, remove the secret from code and history where appropriate, and verify that the old credential no longer works.

Read the case study for the validation scope, limitations and remediation approach.

Passive discovery and authorised validation

Passive discovery examines information already available from public sources. Finding an exposed credential, an apparent relationship or a reference to a system does not establish that access is possible, that an association is correct or that a compromise has occurred.

Validation is a separate decision. Any authentication attempt or other interaction that tests access needs an agreed target, explicit authorisation and defined limits. In the published GitHub engagement, selected checks stopped once authentication was confirmed. They did not include accessing customer data, changing resources or escalating privileges.

Where validation is outside scope or a target cannot be checked, the finding should remain clearly labelled as unverified. An unresolved endpoint or an unsuccessful check is not proof that an exposed secret is safe.

Questions to resolve when scoping the work

• Repository exposure: what information is present in the agreed repositories, configuration files and commit history, and which observations need a separate validation decision? The published GitHub case provides a worked engagement example.

• Public footprint: which public references relate to the approved organisation, domains or brands, and how strong is the evidence for that attribution?

• Incident context: which public observations could help an investigation, and which questions require internal logs or other evidence beyond OSINT?

Agree which questions the engagement will answer before work starts. Discovery from public sources does not replace an internal forensic investigation or establish who used an exposed credential.

What to bring to a scoping discussion

• The business question, intended use of the findings and priority concerns.

• The organisations, brands, domains, repositories and other targets you are authorised to include; identify exclusions and third-party assets.

• Known exposures or relevant context, shared through an agreed channel. Do not put passwords, access tokens or sensitive evidence into the initial contact form.

• A contact who can resolve ownership and scope questions, and the people who will act on findings.

• Any handling restrictions, timing constraints and the decision required before active validation can begin.

Sources, tools and evidence quality

Relevant sources can include public repositories and developer forums, company filings, public records, news reports, websites and social platforms. The source, its date and its relationship to the agreed target matter as much as the information itself.

Search engines, Shodan, theHarvester and Maltego can help locate information or examine relationships. Tool output needs interpretation: a search result or linked entity is a starting point for assessment, not proof of a vulnerability or ownership.

Limitations to account for

• Accuracy and attribution: public information may be wrong, old or associated with a different organisation. Separate confirmed facts from uncertain links.

• Coverage: a large volume of results can hide relevant evidence. An assessment of agreed sources cannot prove the absence of all exposure.

• Change over time: findings describe the evidence available during the assessment; public information and access permissions can change.

• Handling and boundaries: agree the purpose and treatment of personal or sensitive information, even when it is publicly accessible.

Using the findings

Findings should explain where information was found, the confidence in the observation, its relevance to the organisation and the recommended action. Distinguish work that can proceed immediately from checks that need further evidence or authorisation. Use that distinction to assign remediation and decide what to validate next.

Agree delivery and handling before work starts

• Effort and timing: discuss the number of targets, sources, attribution questions and any separately authorised validation. Agree priorities and a schedule around the decision you need to make.

• Sharing findings: agree the report recipients, evidence format, secure delivery channel and whether a findings discussion is required.

• Urgent exposure: nominate an escalation contact and agree how an apparently active credential or other time-sensitive finding should be reported.

• Retention and follow-up: agree evidence handling, retention requirements and any further validation or remediation checks.

Related services

• GitHub credential discovery and validation for repository exposure and a defined validation scope.

• Incident response and forensics when internal evidence is needed to investigate suspected compromise.

• Security assessment services to discuss the wider assessment question.

Discuss an OSINT assessment

Contact ProCheckUp about your OSINT requirements. Include your objectives, the types of target and any timing constraints so that the scope and next steps can be discussed.