Your name appears on a conference website. Your employer announces a new project. A supplier lists your company as a client.
Each detail has an ordinary reason to be public. Read together, they could help someone make an unfamiliar request sound like it belongs in your working day.
For a security team, the useful question is what an attacker could do with that information, and which assumptions would still need to be tested.
Your job title is only the beginning
At Excera, we use “subject OSINT” to describe a focused review of publicly available information about a person and their working context. OSINT stands for open-source intelligence.
A conference biography might identify someone as a finance director. That gives a researcher a dated claim about their role. It does not confirm that they still hold the position, approve payments or have access to a particular account.
Those gaps affect the quality of the assessment. If we silently turn “listed as finance director” into “can authorise a transfer,” we may build an impressive scenario around authority the person never had.
Our proposed method keeps the source, the inference and the scenario separate. A reviewer should be able to reject our interpretation without losing the evidence behind it.
Five minutes to prepare the email
IBM X-Force reported generating a phishing email in five minutes using five AI prompts, compared with around 16 hours for its team's usual preparation. The human workflow included researching the target organisation. The AI version used industry-focused prompts. Read IBM's experiment.
That is a comparison of email preparation, not a stopwatch on gathering information about one person. For a security team, it is a reason to examine how exposed details could feed a convincing request, even when the attacker spends little time writing it.
When a support call asks for access
Google Threat Intelligence’s June 2025 report on UNC6040 describes attackers impersonating IT support over the phone and persuading employees to authorise an application connected to Salesforce. That permission gave the attackers access to organisational data. Google reported that the observed intrusions relied on manipulating users rather than exploiting an inherent Salesforce vulnerability. Read Google’s report.
For a defensive researcher, the case raises a concrete question: under what circumstances would someone accept an access request as legitimate support work?
For an authorised review, we would investigate what the organisation makes publicly visible about its systems and people, then check the hypothesis against its actual support and approval processes.
A plausible attack still needs testing
A public-facing finance role might suggest supplier impersonation as a relevant scenario. Before testing it, we need the organisation’s permission and an accurate understanding of how it handles payment changes.
We also need to preserve the difference between information available to an outsider and information supplied privately for the exercise. Otherwise, we risk presenting a scenario built with internal knowledge as proof of what an attacker could discover publicly.
This is the research method we are developing within Excera’s wider product direction: connect public observations with documented attacker methods, identify a plausible request, then test the decision through an authorised simulation.
The response may challenge the original assessment. Someone whose role looks attractive to an attacker might reject the request immediately. That is useful evidence from the exercise, rather than a reason to insist that the public profile made them “vulnerable.”
Keep the research accountable
The review should have a defined subject, purpose and retention period. Collect what the assessment needs. Contacting relatives, entering private accounts, buying leaked credentials or attempting to sign in as the subject falls outside this proposed public-source method.
The final handoff should let another person inspect the reasoning: source links and dates, what remains uncertain, the request we propose testing, and the control or decision the test would examine.
To help develop this method around your organisation’s working practices, build with Excera.
Sources
Excera analysis, based on the reporting linked below.