Respond to Open Web Events
When you receive an event pointing to an Open Web source, the first step will be to look at the result on the platform using the link provided in the event. If there is a specific result that is of interest to you and you are unsure about how, or whether it's safe to access, feel free to reach out to us, we'll be happy to help.
In general, whenever you see sensitive technical information and can confirm it relates to your firm or assets (e.g.: password, API Key, Token, etc.) the first step is to invalidate it (reset the password, revoke the API Key, etc.). Monitoring for attempts to connect following this can also reveal information on potential attackers.
An event of this type means that Flare found one of your identifiers on a paste site (Pastebin, etc.) or on Google (through Open Web).
The risk varies depending on the type of information found.
In the case of personal information (PII), this can lead to increased and better targeted phishing and spear phishing for the target individual. This risk increases with the authority and power that the individual has - the initial phishing attack can lead to account takeovers, social engineering, and fraud.
In the case of technical information such as credentials, API keys, or access tokens, the risk is similar to the source code risks defined below.
In the case of business information such as financial statements, or project roadmaps it can lead to a loss of competitiveness and credibility on the market.
- Analyze the content of the document or page to understand the risk. Identify the type of information that is leaked.
- In the case of personal information, notify victim employees and warn them to be aware of an increased risk of being targeted by phishing attacks.
- In the case of technical information, follow the recommendations in Source Code below.
Events referring to documents found on sites like Github or StackOverflow are straightforward to investigate.
There are 2 main risks of leaked source code:
- First is that it exposes, directly or indirectly, information about your IT system to malicious actors. This can include hostnames, network routes, IP addresses, credentials, API keys, and access tokens. With these in hand, an actor can achieve initial access to an internet system and/or have information to improve their lateral movement and privilege escalation steps.
- The second risk is exposed intellectual property which can result in loss of competitiveness if accessed by competitors or by malicious actors. In some cases, threat actors will download the data and then sell it on underground channels to third-parties.
- Identify which identifier matched the content, and the overall criticality of this identifier.
- Confirm the relationship between the leaked document and your organization. This includes looking at the code, both in Flare and on the source code repository website (GitHub, GitLab, etc.), and looking at the email of the committer.
- If credentials, API keys, or access tokens are present, launch an incident response, identify and contact the internal teams in charge of the related systems, and rotate the leaked credentials. Assume that malicious actors are also monitoring these events and will have the data even if they are timely removed from the Internet.
- If an employee or active consultant is involved, use the provided template to request from the employee to remove the code. This is by far the easiest way to remove leaked source code from public websites.
- If the individual in question cannot be identified or reached, contact the website through the link provided in the platform and request removal. Websites like GitHub will only accept requests when justification of the risk is sufficient.
Events in the Hosts category indicate that an exposed host was detected and relates to one of your identifiers. In Flare, a host represents a unique service that can be hosted anywhere from a physical device to a cloud container.
Exposed hosts present 2 main risks:
- Exposed services can provide entry points to malicious actors into a network. This includes, for example, exposed SSH ports and RDP ports. This can result in a large-scale breach following other lateral movements and privilege escalations.
- Exposed databases or data-related services can provide access to employee or customer personal information. This includes, for example, exposed MySQL databases, ElasticSearch clusters, or FTP servers. This can result in large fines and brand impact.
- If the results refer to an IP which is owned by your company or your client and is running an HTTP service, use your browser to send a request to the IP:Port combination to gather additional information.
- If a database is exposed, leverage a database exploration tool to gain access to the data.
- If an RDP or SSH port is exposed, identify which team or department owns that specific IP and validate the intent. We generally recommend keeping open RDP ports accessible only through a corporate VPN. Public SSH ports should be as limited as possible, and integrate SSH security best practices.
- If a development or QA service is exposed, validate the intent with the team in charge of the service. These services can often provide access to servers or data in a less-secure way than production servers and can present an interesting entry point for malicious actors.
- Further investigate services like SSH ports or various databases, or refer to the incident through your appropriate channels.
- In the case where it is unclear whether the IP or Host belongs to you, investigate internally to better understand the risk. Keep in mind that accessing data or services belonging to third-parties can be a gray legal area. Keep records of the steps undertaken to justify them to regulators if needed
Events in the Buckets category indicate that a public bucket or blob on Amazon Web Services (AWS), Microsoft Azure or Google Cloud Platform (GCP) has matched one of your identifiers.
Buckets can expose confidential data to malicious actors and can result in small or large scale breaches, leaked customer and employee data, fines and brand impact.
- Browse to the bucket and validate the sensitivity of the exposed information
- If your organization uses the cloud service in question, identify and connect with the team to validate the intent.
- If your organization does not use the cloud service, try to identify the project or department to which the leak is related and validate the intent. Evaluate the possibility of reducing the shadow IT and adding measures to control the use of the cloud platform.