Revisiting OSINT: The Digital Footprint Tracker

For old version, please visit here.

Introduction

Sometimes, the weakest point in an organization’s security is not its firewall, operating system, or application. It is the information that people unknowingly make available to the public.

On October 29, 2026, Binance experienced a major security incident involving unauthorized access to its cryptocurrency wallet infrastructure. The incident became particularly interesting when Binance published its preliminary investigation on November 3.

According to Binance, the attackers used a combination of social engineering, malicious software, compromised employee devices, internal AI tooling, and unauthorized access to wallet infrastructure.

One part of the incident involved a software engineer who was approached through a legitimate job-hunting platform. The employee’s public profile referenced their experience at Binance. The supposed recruiter built credibility through interviews and public social-media information before asking the employee to download a coding assignment containing malicious code.

This was not simply a phishing email or an isolated technical vulnerability. It was a multi-stage campaign that combined information gathering, impersonation, trust manipulation, and technical compromise.

There was also an earlier incident involving tampered software downloaded to install an AI coding tool. Although Binance detected the anomaly and replaced the affected device, information about the employee’s role and colleagues had already been exposed.

The attackers subsequently used compromised employee devices and an internal AI tool as part of their movement toward additional systems.

This incident demonstrates an important point: security is not only about protecting systems from technical vulnerabilities. We must also consider what information is publicly available about our organization, employees, infrastructure, and relationships.

This is where OSINT (Open Source Intelligence) becomes important.

1. What is OSINT?

OSINT is the systematic collection, analysis, and verification of information obtained from publicly available sources.

In cybersecurity, we can consider OSINT as the External System View.

It allows us to examine our organization from a perspective outside our internal network. Information that seems harmless individually may become valuable when combined with other publicly available information.

For example, consider these separate pieces of information:

• A job posting that mentions a particular operating system.
• A professional profile showing an employee’s department.
• A public repository describing an infrastructure project.
• A document containing internal naming conventions.
• A public DNS record identifying an organization’s service.

Individually, these may not reveal anything particularly sensitive. However, together they may provide a better understanding of the organization’s technology environment and the people responsible for operating it.

This is the main concern with a digital footprint.

A single data point rarely tells the complete story. The risk increases when different information sources can be correlated.

It is also important to understand that publicly accessible information is not automatically free to collect, process, or use for any purpose. OSINT activities should have an authorized scope, respect privacy requirements, and avoid collecting information that is unnecessary for the assessment.

2. The Binance Incident: When Public Information Meets Social Engineering

The recent Binance incident is a useful example of how OSINT and social engineering can become connected.

According to Binance’s November 3 preliminary report, the campaign involved several stages.

Public identity and professional information

The targeted employee had a profile on a legitimate job-hunting platform that referenced their experience at Binance.

The attackers approached the employee while impersonating representatives of a fictitious organization.

During the interview process, the supposed HR representative also shared a social-media account containing personal photos and videos to establish credibility.

This is where publicly available information becomes relevant.

An employment profile can disclose an individual’s current organization, professional experience, and general area of responsibility. Public social-media content may also help another person establish familiarity and trust.

The problem is not that employees should never publish professional information.

Professional profiles are useful for career development, networking, and recruitment. However, employees and organizations should understand what information is publicly visible and how it could be misused.

The trust relationship

The incident also demonstrates that social engineering is not limited to suspicious emails.

A fake recruitment process can involve professional platforms, video interviews, messaging applications, and technical assignments.

A person may feel more comfortable when the other party appears to have a credible professional history and communicates through familiar services.

This is why we should not judge a request only by the platform through which it arrives.

A legitimate platform does not guarantee that every person using it is legitimate.

The technical compromise

The incident did not stop at impersonation.

The employee was asked to download a coding assignment containing malicious code. The compromised device subsequently became part of a larger intrusion.

Binance reported that the attackers later used compromised employee devices and an internal AI tool to reach additional employees and obtain access related to wallet infrastructure.

The attackers eventually gained unauthorized access to an internal wallet signing service.

This demonstrates how a human interaction can become the starting point of a much larger technical incident.

The important lesson is that social engineering and technical security are not separate problems. They can work together within the same attack.

Reference: Binance: 29 October 2026 Security Incident, Initial Findings and Response Update

3. Core Factors: What We Focus On and Why

For organizational security assessments, I would divide OSINT into four main categories.

A. Infrastructure Mapping: Where?

The first category concerns the organization’s externally visible infrastructure.

Information may include:

• Public DNS records.
• Domain and subdomain information.
• SSL/TLS certificate history.
• Public cloud service references.
• Internet-facing services.
• Publicly indexed network information.
• Third-party service dependencies.

Why does this matter?

Organizations frequently change their infrastructure.

A service may be migrated to the cloud, a new application may be deployed, or an old server may be forgotten after a migration.

However, the public footprint may still contain references to these resources.

A forgotten service or incorrectly exposed management interface may introduce an additional attack surface.

For example, an organization may have a separate backup environment as part of its DRP. If a backup-related service is unnecessarily accessible from the public Internet, it deserves investigation.

Its presence does not automatically mean the backup has been compromised, but it may indicate that the intended network boundary needs to be reviewed.

During an OSINT assessment, we should compare externally visible information against the organization’s approved asset inventory.

The objective is to identify unexpected exposure, outdated services, and infrastructure that no longer belongs in the public environment.

B. Human and Organizational Information: Who?

The second category concerns employees, management structures, professional relationships, and publicly disclosed responsibilities.

Possible sources include:

• Professional profiles.
• Recruitment advertisements.
• Public company announcements.
• Technical conference presentations.
• Public documentation.
• Employee-created technical content.
• Publicly available organizational information.

Why does this matter?

Job advertisements frequently mention technology requirements.

For example, an organization may advertise positions requiring experience with specific databases, cloud providers, programming languages, or infrastructure platforms.

This information can help us understand the general technology environment.

Professional profiles may also reveal that particular employees work in infrastructure, security, development, database administration, or cloud engineering.

The Binance incident demonstrates why this information deserves attention.

The public profile of the employee referenced their experience at Binance, which formed part of the context in which the fraudulent recruitment approach was made.

We should not blame employees for maintaining professional profiles. Instead, organizations should establish reasonable guidelines about the information shared publicly and provide awareness training about impersonation and suspicious recruitment requests.

C. Metadata and Development Artifacts: How?

The third category concerns information embedded in documents, software repositories, and development processes.

Examples include:

• PDF and Office document metadata.
• Public source-code repositories.
• Commit history.
• Software build information.
• Public documentation.
• Exposed API credentials.
• Configuration files.
• Infrastructure deployment references.

Why does this matter?

Documents sometimes contain more information than their visible contents suggest.

Metadata may reveal author names, software versions, document creation details, or internal naming conventions.

Likewise, public development repositories may contain information that was not intended for public distribution.

An accidentally exposed credential is particularly important because it may provide access to another service.

Deleting the visible file does not automatically invalidate the credential. It may remain in historical commits, copies, or other locations.

Organizations should therefore use secret-scanning tools, review repository permissions, and immediately revoke or rotate credentials that have been exposed.

This is also an area where OSINT and software supply-chain security overlap.

D. Digital Identity and Trust: Who Are We Really Communicating With?

The fourth category is particularly relevant to social engineering.

We need to consider the information used to establish trust between people and organizations.

This may include:

• Company websites.
• Recruitment communications.
• Public executive profiles.
• Vendor identities.
• Domain and email authenticity.
• Public announcements.
• Third-party business relationships.

The Binance incident showed that an apparently legitimate recruitment process can still be used to establish a false identity.

A familiar platform, a professional-looking profile, or a live video interview should not independently establish that the person or organization is genuine.

We need to verify identities through trusted and independently established communication channels.

4. The Connection Between OSINT and Social Engineering

OSINT and social engineering are closely related, but they are not the same thing.

OSINT provides information that can help someone understand an organization, its employees, and its technology environment.

Social engineering uses communication and trust to influence people into taking actions that may compromise security.

OSINT can make social engineering more convincing because the communication may contain accurate information about the person’s work, organization, or professional interests.

However, social engineering does not always require an extensive OSINT investigation.

The Binance incident illustrates how publicly available professional information, impersonation, and a seemingly ordinary recruitment process can become part of a much larger compromise.

For organizations, this means security awareness should not focus exclusively on suspicious email attachments or unknown links.

It should also include:

• Unexpected interview assignments and software requests.
• Unverified recruiters and business representatives.
• Requests to install unfamiliar development tools.
• Unusual requests involving credentials or access permissions.
• Unexpected changes to established communication channels.
• Requests that bypass normal approval procedures.

Technical employees should have an approved process for evaluating unfamiliar repositories, software packages, and development tools before using them on work devices.

An employee should never be expected to make a security decision alone when a request involves unfamiliar software or elevated permissions.

5. AI-Assisted OSINT: The First Screening Layer

This is where I think AI can make OSINT more useful in everyday security operations.

Traditional OSINT involves collecting information from different sources and manually reviewing whether it is relevant to the organization.

The problem is that information is distributed across many platforms and formats.

Some findings are harmless. Others may indicate a security weakness. Some may simply be outdated information.

AI can help perform the initial screening and correlation.

I would introduce AI as the first screening layer, not as the final security authority.

A. First-pass content analysis

When an employee receives something suspicious, AI can help review the available information.

For example:

• An unexpected recruitment message.
• A request to download a technical assignment.
• A suspicious software installation notice.
• An unfamiliar vendor communication.
• A document containing unexpected references to infrastructure.
• A public repository that appears unrelated to its stated purpose.

AI can help summarize the content, identify inconsistencies, and highlight elements that require additional verification.

The objective is to help people recognize suspicious information before acting on it.

B. Identity and source verification assistance

AI can help compare the information in a communication with known, approved organizational information.

For example, it may identify:

• Differences between an expected and supplied company domain.
• Inconsistencies in organization names.
• Unexpected changes in communication channels.
• Claims that cannot be supported by the available official information.
• Links or references that require independent verification.

However, an AI system cannot prove that a person is genuine simply because their profile appears consistent.

Human verification through an established and trusted contact channel is still necessary.

C. External footprint correlation

For an authorized organizational assessment, AI can help correlate public information with an approved asset inventory.

For example:

• A public service that does not appear in the current asset inventory.
• An outdated software reference in public documentation.
• A public document containing unexpected internal information.
• A repository exposing configuration information.
• A public certificate or domain record that needs review.

The result should be a list of findings with supporting evidence and an explanation of why each item deserves attention.

D. Classification and prioritization

I would divide the initial AI assessment into three practical categories:

This classification should not be confused with a formal VAPT risk score.

AI should explain what it detected and provide references to the supporting evidence.

The security expert then confirms whether the finding is genuine.

E. Continuous monitoring

OSINT should not be treated as a one-time activity.

Public information changes constantly.

New employees join, job advertisements are published, domains are registered, applications are deployed, and software repositories are updated.

AI can help monitor changes against an approved organizational scope and notify the security team when something unexpected appears.

This creates an ongoing external-footprint monitoring process.

6. AI Is Also a Target That Needs Protection

There is another important lesson from the Binance incident.

According to its preliminary report, attackers used an internal AI tool as part of the campaign to gain access to additional employee devices.

This does not mean that AI itself caused the incident. It demonstrates that an AI-enabled service can become part of an organization’s attack surface when its environment or access is compromised.

Organizations are increasingly integrating AI into development, operations, document management, and infrastructure administration.

These systems may have access to internal information or connected tools.

We therefore need to include AI platforms in our own security assessments.

Some considerations include:

• Who can access the AI system?
• What information can it retrieve?
• Which external services can it communicate with?
• Does it have access to sensitive repositories?
• Can it interact with internal applications?
• Are its permissions limited to the tasks it needs?
• Are its actions recorded and monitored?
• Can an employee distinguish between an AI recommendation and an approved instruction?

For OSINT operations, I would also avoid sending confidential employee information, customer records, private infrastructure diagrams, or credentials to an unapproved external AI service.

AI should help protect organizational information, not become another place where that information is exposed.

7. How to Check Your Own Digital Footprint

To understand your organizational exposure, you need to look at your environment from the outside.

I would organize this into four defensive assessment activities.

A. External Infrastructure Review

Start with domains and public assets that your organization owns or is authorized to assess.

Review:

• Public DNS information.
• Certificate records.
• Publicly visible services.
• Cloud-hosted resources.
• Outdated external references.
• Unexpectedly exposed management interfaces.

Services such as Shodan and Censys can help show how an organization’s public-facing infrastructure appears to external observers.

However, a search result is an observation, not proof of a vulnerability.

Confirm that the asset belongs to the organization and verify its actual configuration before making conclusions.

B. Public Information Review

Review what the organization has published through:

• Official websites.
• Job advertisements.
• Public technical documentation.
• Professional profiles.
• Conference presentations.
• Press releases.

The objective is to understand whether the information being shared is appropriate and whether it reveals unnecessary operational details.

There is no need to eliminate all public information. The goal is to understand its security implications.

C. Document and Repository Review

Review publicly accessible documents and development repositories belonging to the organization.

Check for:

• Sensitive metadata.
• Internal naming conventions.
• Unintended configuration exposure.
• Credentials or tokens.
• Old infrastructure references.
• Information that should no longer be publicly accessible.

If credentials are exposed, revoke them rather than simply removing the visible content.

D. Credential Exposure Review

Credential exposure is another important concern.

Services such as Have I Been Pwned can help individuals check known breach exposure.

For organizations, domain-wide searches require domain ownership verification or appropriate authorization.

A reported breach does not automatically mean that the employee’s current corporate password is compromised. We need to establish whether the exposed information is still relevant and take appropriate action.

Organizations should combine breach monitoring with MFA, credential rotation when necessary, and monitoring for suspicious authentication activity.

8. From OSINT to VAPT: Turning Information into Security Improvements

OSINT and VAPT complement each other, but they have different purposes.

OSINT identifies publicly available information and potential external exposure.

VAPT evaluates security weaknesses through an authorized technical assessment.

For example:

OSINT findings should not automatically become confirmed vulnerabilities.

They are intelligence that helps determine where additional investigation may be necessary.

AI can assist in organizing these findings and suggesting which ones require attention first.

The security expert should then validate the evidence and determine whether further VAPT work is appropriate.

9. A Practical OSINT Workflow for Organizations

I would use the following workflow when adding OSINT to an organizational assessment.

Step 1: Define the assessment scope

Identify the organization’s approved domains, public assets, repositories, and information sources.

Establish which information may be collected and who is authorized to review it.

Step 2: Collect public information

Gather information from approved public sources, including company websites, DNS records, public documentation, repositories and relevant service indexes.

Step 3: Normalize the findings

Organize information by asset, service, department and source.

Remove duplicate records and identify outdated information.

Step 4: AI-assisted first screening

Use AI to classify information, identify possible inconsistencies, and highlight suspicious findings.

Step 5: Expert verification

Confirm whether the findings are accurate, relevant and associated with the organization’s actual environment.

Step 6: Risk assessment

Evaluate the potential impact, exposure, sensitivity, and possible misuse of each confirmed finding.

Step 7: Mitigation

Determine whether information should be removed, corrected, access-restricted, or protected through additional security controls.

Step 8: Reassessment

Review the external footprint again to verify that the changes have taken effect.

This process can become part of an organization’s regular security assessment rather than an isolated research activity.

Conclusion

I think OSINT deserves more attention in modern security assessments.

Organizations spend considerable effort securing networks, servers, databases, applications, and cloud infrastructure. However, information about these systems and the people responsible for them is often publicly available.

The recent Binance incident demonstrates how publicly available professional information, social engineering, and technical compromise can become connected in a sophisticated campaign.

We should not assume that a technically secure environment is automatically protected from manipulation through human trust.

AI can help us take the first look at suspicious information, correlate external findings, and highlight issues that deserve investigation. However, it should not make final security decisions or replace professional verification.

The objective is not to hide everything from the public.

It is to understand what information we expose, whether it is necessary, and how it could affect the security of our organization.

Security begins before someone reaches the firewall. Sometimes, it begins with the information we have already made public.

References and Resources

• Binance: 29 October 2026 Security Incident, Initial Findings and Response Update
• Reuters: Binance hackers used fake job interview in $6.3 billion attack, November 3, 2026
• BleepingComputer: Binance says fake job interview led to $6.3 billion crypto heist
• Microsoft Security: Contagious Interview, Malware Delivered Through Fake Developer Job Interviews
• Have I Been Pwned
• Shodan
• Censys
• OWASP

For additional technical resources, see gfxtm Resources & Tools.