Using the Dashboard
The Dashboard Module is the visual intelligence hub of the ThingsRecon Discovery platform. It aggregates and displays key insights from discovery scans and timeline-based comparisons, providing a real-time and historical view of an organisation’s:
- complete digital footprint
- overall ‘cyber hygiene’ posture
- risk exposure and attack surface insights.
The Dashboard presents data visually, contextually and interactively, making it a powerful decision-making tool.
The colour coding of applications in the different dashboard views (Heatmap, World Map, Things) is based on hygiene indicators where Green = Good, Red = Requires attention.
The risk rating is assigned according to the following criteria:
A | B | C | D | F |
A | B | C | D | F |
Excellent | Good | Average | Poor | Failing |
Exhibits robust cyber hygiene with no outstanding issues. Demonstrates best practices in Web Security. | Good security with minor areas for improvement. | Meets basic security requirements with significant improvement areas. May use outdated software. Potentially vulnerable to sophisticated attacks. | Lacks sufficient security measures, exposing it to numerous cyber hygiene issues. | Fails to implement basic security controls, exposed and very likely to be attacked. |
Heatmap View
The Heatmap View is a high-level visualisation of issues by severity and category. It provides information about Discovery, Hygiene, and Attack Surface Reduction, and this data is broken down by business unit and location. (See Filtering with Indicators for more.)
This is the default view you'll see on your Dashboard when you log in. It quickly pinpoints your highest risks, so you can take swift and appropriate action.
The Heatmap View offers multiple ways to visualise data, including:
- Circular Chart: Provides an overall rating. That could be across all Things discovered; for specific items; or based on selected filter options
- Banner Stats: Values shown are based on selection and filtering criteria, from global insights down to those at a more granular level:
- Specific business units
- Individual countries
- Domains
- Applications
- Expandable Sections: for more detail by:
- Discovery – Status of discovered assets
- Hygiene – Breakdown of indicator type and severity
- Attack Surface Reduction – Actions needed to reduce exposure.
Hover over any Heatmap block to open a mini menu that will allow you to:
- Launch a report using a pre-defined template
- See updated banner stats for a particular domain/item
- View detailed breakdowns.
Alternatively, use the breadcrumb navigation on the left to drill down into specific locations and see how they're performing.
Use the breadcrumb to filter by:
- Business Units: to view assets relevant to teams, subsidiaries, or clients
- Locations: showing the geographical distribution of assets and risks (automatically populated from scan results).
The Heatmap is divided into three sections: Discovery, Hygiene, and Attack Surface Reduction.
Navigating the Timeline
The Timeline at the bottom of the Dashboard highlights test results over time, enabling valuable comparisons and a deeper understanding of an organisation’s evolving cyber security posture.
Each entry here displays:
- The test date
- A colour-coded hygiene indicator (Green = Good, Red = -Requires Attention)
- A five-level cyber-hygiene rating, from A–F
You can use the Timeline Navigator to switch between historical test results via the Dashboard, including the corresponding scan results and hygiene ratings.
Tip: Use the Timeline Navigator to measure security posture changes over time. |
World Map View
The World Map View (accessible via the drop-down menu) highlights where risks are located geographically. It displays the physical distribution of discovered assets, showing the concentration of risks across different countries. This means it can be used to understand the relative or changing situation in priority locations.
Again, you can filter data by Discovery, Hygiene, and Attack Surface Reduction. But with this view you can zoom in to see hygiene issues and attack surface reduction opportunities in specific locations.
Regions are colour-coded to indicate their overall hygiene ratings, and users can view additional information about Discovery, Hygiene, and Attack Surface Reduction in the right-hand panel.
Tip: Use the Heatmap and World Map views for executive-level visualisations. |
Things View
The Things View is a deep-dive, Configuration Management Database (CMDB) - style interface that categorises all discovered “Things”, including:
- Applications
- API endpoints
- Domains
- IPs
- Certificates
- Cookies, etc
Select different types of “Things” using the selection bar in the upper-right corner.
Each “Thing” type opens in a table view with:
- Filterable columns
- Bulk actions
- Direct links to detailed Passport Views.
This view is ideal for asset inventory, triage and tagging.
Tip: Use the Things View for operational actions like tagging, onboarding or triaging. |
(See Detailed “Things” Guide for more.)
Filtering with Indicators
The dashboard view provides actionable insights by indicating issues and opportunities related to discovery, hygiene, and attack surface reduction. In heatmap view, these indicators are displayed in a window above the heatmaps. You can expand this view by clicking the expand icon in the top-left corner. You can also click on an application to open a ‘passport’ view, where indicators are shown in a small summary.
In the world map view the indicators are shown in a column on the right side of the map.
In both views, you can click on specific entries to see filtered indicators relevant to specific areas and business units.
You can also click on the indicators themselves to go to the Things view and see a list of the relevant discovered ‘things’ (applications, domains, devices/IP addresses, certificates, cookies, and so on).
Discovery Indicators
Indicator | Description |
External API | Application where an external API was discovered which is external to the project (organisation)
|
Forbidden | Responsive application that always returns 403 error |
Internal API | Application where an internal API was discovered which is internal to the project (organisation)
|
Live application | Reachable application having the status “online”, “SSO” or “unauthorised”. Other statuses can be considered as live applications as well. Responsive applications running on Fully Qualified Domain Names (FQDNs) having “Forbidden” or “Not found” status are also considered as live applications |
Not found | Responsive HTTP or HTTPS address (FQDN or IP) that always returns 404 error. No available pages could be found |
Parked Domain Applications | At first glance, a responsive application, however the FQDN belongs to a parked domain name (domain for sale or reserved domain name) |
Redirecting | Responsive HTTP or HTTPs address (FQDN or IP) that redirects to another web application |
Refused | No connection could be made because the target machine actively refused it |
SSO | Application protected by a Single Sign On (SSO) portal. The application cannot be directly reached but rather redirects to single sign-on solution |
Third party | Application identified as one of a known software vendor. This can be a SaaS platform or on-premise product. ThingsRecon Discovery covers a large number of solutions that could be CRMs, security equipment portals or file transfer solutions |
Unauthorized | Responsive application that always returns 401 error. An application returning 401 error followed by realm authentication system is not considered unauthorised but rather an online application having a login form. This status is assigned to applications returning a 401 error without any ways to authenticate |
Hygiene Indicators
Indicator | Description |
|
|
Clear login form | Reference: CWE-319: Cleartext Transmission of Sensitive Information. Applications that transmit data over unencrypted connections make themselves vulnerable to interception. Vulnerabilities that result in the disclosure of users' data can result in compromises that are extremely difficult to investigate due to obscured audit trails. Personally Identifiable Information (PII) can be later used for phishing attacks amongst others |
Cookie consent issue | The application was found to issue cookies upon navigating to the application without requiring the user to accept the use of the cookies. As of May 2011, countries within the EU are required to give users the right to refuse the use of cookies that may be detrimental to their online privacy. In the UK, this is reflected in the Privacy and Electronic Communications Regulations. This is commonly known as the Cookie Law |
Compromised applications | Using an application that has been part of a data breach may pose severe risks, including unauthorised access to user accounts, data theft, and identity fraud. This can result in significant financial losses, compromised sensitive information, and long-term damage to personal and organisational reputation |
CSP heading misconfiguration | Reference: CWE-79 - (Improper Neutralisation of Input During Web Page Generation, aka Cross-site Scripting or XSS). The Content-Security-Policy header was designed to modify the way browsers render pages, and thus to protect from various cross-site injections, including Cross-Site Scripting. It is important to set the header value correctly, in a way that will not prevent the proper operation of the website. For example, if the header is set to prevent the execution of inline JavaScript, the website must not use inline JavaScript in its pages |
Dangling DNS | Reference: CWE-16: Weakness in Configuration of DNS Records. Assess if subdomain takeover is possible with the provider. Dangling DNS refers to DNS records that may no longer be in use and may point to non-existent or expired domains, potentially directing users to malicious sites controlled by attackers. This can lead to phishing attacks, malware downloads, and unauthorised data collection, compromising user security and damaging organisational reputation. Regular monitoring and maintenance of DNS configurations are crucial to mitigate these risks |
Deprecated SSL Cipher Category | Deprecated SSL ciphers poses serious security risks, including vulnerability to advanced cryptographic attacks that can decrypt or alter sensitive data. This compromises the confidentiality and integrity of communications, potentially allowing attackers to access or manipulate information exchanged between clients and servers |
Deprecated SSL Protocol | Using deprecated SSL protocols exposes a domain to significant security vulnerabilities, including susceptibility to various attacks such as man-in-the-middle attacks, where attackers can intercept and alter communications. It also weakens the encryption, making it easier for cybercriminals to decrypt sensitive information, compromising data confidentiality and integrity |
Exposed database | From port scanning, an DB access port was discovered exposed to internet (MSQL, PostgreSQL, MS SQL...) |
Exposed file-sharing server | From port scanning, a file-sharing server was discovered exposed to internet (FTP, SMB...) |
Exposed remote access service | From port scanning, a remote access service was discovered exposed to internet (SSH server, RDP...) |
HREF misconfiguration | An application with invalid HREF references can lead to broken links, resulting in poor user experience and reduced website credibility. Additionally, it can negatively impact SEO rankings and hinder navigation, potentially causing users to leave the site |
HSTS Header Misconfiguration | HTTP Strict Transport Security (HSTS) can be configured on application servers to indicate that future connections to the server should use HTTPS connections. This can mitigate a number of attacks where an attacker may try to manipulate a user's connection to use an unencrypted connection. For example: Performing SSL stripping, an attacker sitting between a client and server can communicate with a client on regular unencrypted HTTP. The client can see that the session is not encrypted, but critically, the client doesn't know that the session is supposed to be encrypted. HSTS solves this problem by telling the client's web browser that all connections to the domain should be encrypted until at least a certain date. Or, if the web application mixes usage of HTTP and HTTPS, an attacker can manipulate pages in the unsecured area of the application or change redirection targets in a manner that the switch to the secured page is not performed or done in a manner, that the attacker remains between client and server. If there is no HTTP server, an attacker in the same network could simulate an HTTP server and motivate the user to click on a prepared URL by a social engineering attack |
HTTP responsive IP | Web applications should not reply to client requests using an IP-based URL |
Invalid certificate | Reference: CWE-295 - Improper Certificate Validation. Invalid certificates pose security risks such as exposing user data to interception by third parties and enabling man-in-the-middle attacks. Users may be deterred from using the application due to security warnings, potentially leading to loss of trust, reduced adoption, and reputational damage for the organisation |
Malicious Clone | Maliciously cloned applications typically use spoofed, copycat or Typosquat domains and are intended to trick unsuspecting users into visiting a malicious clone of an otherwise legitimate application. Users unknowingly accessing a maliciously cloned application may become victims of malware downloaded via the cloned application (aka 'drive-by-downloads') |
Missing CSP headers | Reference: CWE-79 - (Improper Neutralisation of Input During Web Page Generation, aka Cross-site Scripting or XSS). The Content-Security-Policy header was designed to modify the way browsers render pages, and thus to protect from various cross-site injections, including Cross-Site Scripting. It is important to set the header value correctly, in a way that will not prevent the proper operation of the website. For example, if the header is set to prevent the execution of inline JavaScript, the website must not use inline JavaScript in its pages
|
Missing HSTS Header | HTTP Strict Transport Security (HSTS) can be configured on application servers to indicate that future connections to the server should use HTTPS connections. This can mitigate a number of attacks where an attacker may try to manipulate a user's connection to use an unencrypted connection. For example: Performing SSL stripping, an attacker sitting between a client and server can communicate with a client on regular unencrypted HTTP. The client can see that the session is not encrypted, but critically, the client doesn't know that the session is supposed to be encrypted. HSTS solves this problem by telling the client's web browser that all connections to the domain should be encrypted until at least a certain date. Or if the web application mixes usage of HTTP and HTTPS, an attacker can manipulate pages in the unsecured area of the application or change redirection targets in a manner that the switch to the secured page is not performed or done in a manner, that the attacker remains between client and server. If there is no HTTP server, an attacker in the same network could simulate an HTTP server and motivate the user to click on a prepared URL by a social engineering attack
|
Missing Referrer Policy Header | The 'Referrer-Policy' header was designed to prevent cross-domain Referrer leakage. It is a request header that indicates the site from which the traffic originated. If there is no adequate prevention in place, the URL itself, and even sensitive information contained in the URL, will be leaked to the cross-site. The lack of a Referrer-Policy header might affect the privacy of the users and the site itself
|
Missing X-Content Type Options Header | MIME-type checking utilises standard functionality in browsers to find an appropriate way to render data where the HTTP headers sent by the server are either inconclusive or missing. This allows older versions of Internet Explorer and Chrome to perform MIME-sniffing on the response body, potentially causing the response body to be interpreted and displayed as a content type other than the intended content type |
Missing X-Frame Options Header | The 'X-Frame-Options' HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites. Different user agents may respond differently when processing more than one X-Frame-Options header |
Old components | Reference: A06:2021 - Vulnerable and Outdated Components. It is important that all software components be maintained at the latest version, as older versions are likely affected by one or more publicly disclosed vulnerabilities |
Privacy policy issue | Not having a privacy policy on a company's web application or website can lead to legal and regulatory non-compliance, exposing the company to fines and legal actions. Additionally, it undermines user trust, as customers may be concerned about how their personal data is collected, used, and protected, potentially reducing user engagement and harming the company's reputation. |
Referred Policy Header Misconfiguration | The 'Referrer-Policy' header was designed to prevent cross-domain Referrer leakage. It is a request header that indicates the site from which the traffic originated. If there is no adequate prevention in place, the URL itself, and even sensitive information contained in the URL, will be leaked to the cross-site. The lack of a Referrer-Policy header might affect the privacy of the users and the site itself. |
Suspicious subdomain | Reference: CWE-16: Configuration & CWE-200: Information Exposure. Check if Dev, Test environments should be accessible without authentication to the public |
Web server default page | Reference: CWE-200 - Information Exposure. This web server has a default welcome page. By default, many web and application server software packages are configured with a number of default or initial installation information pages. These 'welcome' pages often reveal software information. Should an attacker be able to determine the type and version of web application software in use, they may be able to focus on specific vulnerabilities associated with the software present. This can make the process of attempting exploitation more straightforward and accurate. Obtaining this information can also result in an estimation of the underlying platform and hardware present |
X-Content Type Options Header Misconfiguration | MIME-type checking utilises standard functionality in browsers to find an appropriate way to render data where the HTTP headers sent by the server are either inconclusive or missing. This allows older versions of Internet Explorer and Chrome to perform MIME-sniffing on the response body, potentially causing the response body to be interpreted and displayed as a content type other than the intended content type |
X-Frame Options Header Misconfiguration | The 'X-Frame-Options' HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites. Different user agents may respond differently when processing more than one X-Frame-Options header |
Attack Surface Reduction Indicators
Indicator | Description |
|
|
Fix | Live application with an obvious hygiene misconfiguration to be fixed. Live applications where the recommended action is Protect or Remove are not listed here |
Onboard | Live application not having any obvious hygiene misconfiguration to fix and not assigned to any security programs |
Protect | Suspicious applications should have limited access (VPN, IP whitelist…) |
Remove | HTTP Responsive IP, web server default page or unexpected opened ports should be removed from exposure |
Certificate, Domain and Network Indicators
There are several more indicators relating to certificates, networks, and domains that are currently only included within exportable reporting, but which will be added to the user interface in an upcoming update.
Indicator | Description |
Certificates | |
Certificate weak key | The service was found to have used an SSL certificate chain that had been signed using a cryptographically weak hashing algorithm (e.g., MD2, MD4, MD5, or SHA1). These signature algorithms are known to be vulnerable to collision attacks. An attacker can exploit this to generate another certificate with the same digital signature, allowing an attacker to masquerade as the affected service. Note that all SSL certificate chains signed with SHA-1 that expire after January 1st, 2017, are considered vulnerable. This is in accordance with Google's gradual sunsetting of the SHA-1 cryptographic hash algorithm |
Deprecated Signature Algorithm | Certificate signature algorithms such as MD2, MD4, MD5, or SHA1are known to be vulnerable to collision attacks. An attacker can exploit this to generate another certificate with the same digital signature, allowing an attacker to masquerade as the affected service |
Expired | An expired SSL certificate can use multiple problems such as a user's browser has no way to validate the server, meaning it cannot definitively determine if the website presenting the certificate is legitimate. This may result in a browser error declaring the connection as not secure and may effectively block the website on modern browsers. A site using HTTP Strict Transport Security (HSTS) will not allow the option to load the page despite this error due to it forcing secure connections |
Expiring (30 days) | An expired SSL certificate can use multiple problems such as a user's browser has no way to validate the server meaning it cannot definitively determine if the website presenting the certificate is legitimate. This may result in a browser error declaring the connection as not secure. This can effectively block the website on modern browsers. A site using HTTP Strict Transport Security (HSTS) will not allow the option to load the page despite this error due to it forcing secure connections |
Revoked | A revoked digital certificate on an application indicates that it is no longer trusted due to identified security issues or compromises. This can result in access disruptions for users, potential vulnerabilities to unauthorised access or data interception, and damage to the application's credibility and reputation due to perceived security weaknesses |
Self-signed Certificate | An application or host was found to rely upon a self-signed certificate to secure communications. The application or host did not have an SSL certificate that was signed by a trusted certification authority. If the clients connecting to this service do not have an explicit trust for this certific ate or certification authority, they will receive an SSL error. If users become accustomed to accepting SSL errors, it is more likely that an attacker performing a Man-in-the-Middle attack will go unnoticed |
Domains | |
DNSSEC not implemented | A domain not using DNSSEC (Domain Name System Security Extensions) is vulnerable to various types of cyberattacks, such as DNS spoofing or cache poisoning, where attackers can redirect traffic to malicious websites without the users' knowledge. This can result in significant security risks, including data breaches, phishing attacks, and the interception of sensitive information |
Email Authentication Gap | The domain has a Mail Exchange (MX) record configured, allowing it to send and receive emails. However, the absence of DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting & Conformance) protocols creates a significant vulnerability. Without these authentication mechanisms, malicious actors can spoof emails that appear to originate from the domain, potentially leading to phishing attacks, fraudulent activities, or damage to the domain's reputation. This misconfiguration weakens email security and trust, making it easier for attackers to exploit the domain for impersonation purposes |
Email Disclosure | Publicly-available email addresses associated with a domain are vulnerable to spam, phishing attacks, and email spoofing, which can lead to security breaches and compromised personal information. These addresses can also be harvested by malicious actors for targeted attacks, increasing the risk of social engineering exploits and business email compromise scams |
Expired | An expired domain can be hijacked by malicious actors, leading to unauthorised control over associated services and email accounts. This can result in data breaches, phishing attacks, and the loss of business reputation and customer trust |
Expiring (30 days) | A domain that is near expiration risks being acquired by malicious actors who could use it for phishing attacks, distributing malware, or impersonating legitimate services. Additionally, the expiration could lead to disruption of services, loss of website visibility, and potential legal issues if critical business operations depend on the domain |
Insufficient SPF data | An incorrectly configured SPF (Sender Policy Framework) record for a domain can lead to legitimate emails being marked as spam or rejected, causing communication disruptions. Moreover, it weakens the domain's defence against email spoofing and phishing attacks, allowing malicious actors to send fraudulent emails that appear to originate from the trusted domain |
New Domain | The domain has been registered within the last 90 days |
Parked Domain | Domain found as parked by registrar. It’s not usable on the internet, as it’s considered as registered. Sometimes, it’s for sale |
Pending Deletion | A domain that is pending deletion faces risks such as loss of control and ownership, which can lead to service disruptions and loss of website functionality. Additionally, once deleted, the domain becomes available for registration by others, potentially enabling cyber squatters to exploit the previous domain's reputation or mislead its users |
Pending Renew | A domain registration in a pending state risks being vulnerable to hijacking or unauthorised changes before it is fully secured. This could lead to loss of control over the domain, disruption of services, and potential exploitation by malicious actors for phishing or malware distribution, impacting both business operations and reputation negatively |
Transfer Protection not enabled | The lack of domain transfer protections, such as domain locking or transfer authorisation codes, increases the risk of unauthorised domain transfers, where cybercriminals can hijack the domain. This can lead to loss of control over the domain, service disruptions, and potential misuse of the domain for malicious activities, damaging the brand's reputation and security |
Network | |
Blacklisted IP | Public IP addresses appearing on a blacklist can lead to blocked communications, preventing access to essential services like email and websites. This can disrupt business operations, damage reputation, and necessitate time-consuming and costly remediation efforts to restore normal functionality |
IP Location | An IP address associated with a x-risk region may indicate increased likelihood of malicious activities originating from that location, such as cyberattacks, malware distribution, or phishing campaigns. Organisations may face higher risks of unauthorised access attempts, data breaches, and compromised network security when dealing with traffic from such regions, necessitating heightened vigilance and robust security measures to mitigate potential threats effectively |
Compare With
A single Discovery scan is useful, but the ability to make comparisons and monitor changes and improvements over time provides even more powerful (and actionable) insights. It can highlight progress (useful for executive reporting), as well as new or developing areas of concern.
When a scan or test data set is selected from the timeline, use the “Compare with” feature to add context and meaning.
Click on the “Compare with” text in the main header section and select another data set to launch a side-by-side comparison, highlighting:
- What’s new
- What’s changed
- What’s resolved.
Tip: Use Compare With for monthly, quarterly or post-incident evaluations. |
After entering the comparison mode, the central panel transforms into a three-part comparison view:
- Discovery: Highlights assets that were added or removed
- Hygiene: Shows new, resolved, or changed hygiene indicators
- Attack Surface Reduction: Displays changes in action-required applications and services.
To return to the standard scan view, click the “X” next to the scan timestamp at the top of the central view panel.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article