• Nick Ascoli

How to perform a third party risk assessment – for mostly free! Part 2 of 3



Part 2: Passive techniques that require no* permission.


*The author of this post is not a lawyer and makes no guarantees nor indemnifications regarding the content contained herein.



Part 1 of this series—How to perform a third party risk assessment – for mostly free—examined a cost-effective approach to Third Party Risk Assessments by engaging simple intelligence-gathering techniques through free sources. The results garnered from the assessments contain critical implications regarding the safety, security, and hygiene of the targeted organization.


In Part 2, we provide an implementation roadmap with step-by-step instructions to execute your third party risk assessment. Specifically, we provide basic instructions on the optimization of open-source tools that will allow you to:

  1. Enumerate systems and implied vulnerabilities.

  2. Analyze the footprint of account exposure.

  3. Check for organization domain presence in malware delivery.

  4. Enumerate GitHub repositories and scan for secrets.




Instructions for executing these assessment techniques:



1. Enumerate systems and implied vulnerabilities with shodan-eye:

  • Requirements:

  • Shodan API Key

  • Tools:

  • https://github.com/BullsEye0/shodan-eye

  • Instructions:

  • Acquire a shodan API key by creating an account on shodan.io.

  • Clone the Shodan-eye tool and install the requirements.

  • Run the tool in the commandline, entering the Shodan API key when prompted.

  • The user will be prompted to enter search keywords. They can use any of the search terms listed on the search filters page. In the example below, a simply hostname search is performed against a domain. Here, one could search for hosts associated with a specific domain, organization, ISP, ASN, etc.

  • In the results of the search are numerous hosts associated with the domain I entered above. For due diligence, I can also simply search in the Shodan UI for more information about potential vulnerabilities on the host, based on exposed ports and services.

  • By viewing the specific vulnerability information, we are able to perform a basic hygiene assessment on public facing systems which are associated with our domain or organization in question. Confirmation of found vulnerabilities should be performed or requested from the system owners, as these vulnerabilities are implied based on detected software and versions.


2. Discover exposed accounts with acctINT:

  • Requirements:

  • HaveibeenPwned API Key

  • Hunter.io API Key

  • Tools:

  • https://github.com/Foretrace/acctINT

  • Instructions:

  • Acquire the necessary API keys for Hunter.io (free) and Haveibeenpwned ($3.50/mo)

  • Clone the acctInt tool into and install the requirements

  • Enter the arguments for the domain to search, as well as the required API keys

  • acctINT will then collect all accounts associated with the domain from hunter.io

  • Once footprinting the specific accounts, acctINT will display the locations of the accounts online (where one can go to learn more about the target), and any breaches/paste site entries where the accounts have been found.

  • An understanding of the exposure of the organizations accounts can shed light onto its procurement practices. While accounts with a large number of breaches does not directly reflect on account management practices, it may reflect a lack of enforcement of acceptable account use policies, as employees may be using work accounts, which can access company assets, for personal use with services which have been the subject of a data breach. Presence on a paste site should be investigated, as paste sites are occasionally used for data exfiltration or account dumps by cyber adversaries. If the paste was relatively recent, the organization who made the discovery should inform the organization involved in the paste - to confirm they are aware of the potential security issue


3. Check for organization domain presence in malware delivery using the URLHaus csv database.

  • Requirements:

  • None

  • Tools:

  • https://urlhaus.abuse.ch/api/

  • Instructions:

  • Visit the urlhaus API page to download a csv of all domains reported to its malware URL service

  • Unzip the archive, and search it for the presence of domains and subdomains associated with the organization or domain. The presence of the organizations domain(s) in this list may indicate the domain or subdomain was hijacked and used to deliver malware. A domains presence in this list may reflect a lack of centralized logging and detection maturity, especially concerning internet facing hosts. Appropriate SIEM rules or host-based behavioral models were likely not in place to detect anomalous behavior on the host, and the security controls on the host did not detect the malicious activity.


4. Enumerate GitHub repos and scan for secrets with gitleaks:

curl -s "https://api.github.com/orgs/{OrgName}/repos" | grep html_url | sort | uniq | awk -F \" '{print $4}' | tail -n +2 
  • Clone the gitleaks repo and install the requirements

  • Run each discovered repo through the gitleaks tool to look for secrets. If secrets are indicated, I recommend running the scan again with the ‘-v’ argument, to view the details of the discovered secret. This will allow the user to confirm the match was a true positive. The presence of secrets in public code may indicate a lack of security controls in the DevOps and/or CI/CD pipeline within the organization, and a lack of proper secrets management policy enforcement or controls within the organization

Note: It may prove valuable to run gitleaks against any users accounts who have made commits to any of the organizations repos, or are members of the organizations. Presence of corporate secrets within user accounts may indicate improper use of employee development accounts, and also be a reflection of DevOps maturity and controls





Scan Result Analysis


The execution of these techniques offers insight into the attention given to the public footprint of an organization’s digital presence. The data obtained can reflect the level of enforcement of security policies, which should also be reviewed as a part of the Third Party Risk Assessment process. The techniques discussed here will not produce traffic or logs on the target organizations infrastructure, allowing some intelligence collection early in the procurement process to eliminate potentially problematic third parties and vendors from the selection process.


If the execution of these techniques manually simply does not scale for your organization, click here for a demo of the Foretrace platform, where we have built a comprehensive tool to automate the execution, analysis, and monitoring of these techniques and many more. In Part 3 of this series, we will discuss the techniques which require ‘active’ scanning of the target organizations infrastructure, which may be executed in the latter phases of procurement of a vendor or third party and may require permission from the vendor to execute.