Advice and answers from the Catcher24 team
Search for the articles here or browse the categories below.
Browse by topic
Find guides, tutorials, and answers organised by category.
Billing
Payment, invoicing and packages you will find it all here.
Dashboard Help
Guides on how to use the dashboard
Web application scanning
Phished
Security awareness and phishing simulations with Phished, directly in your Catcher24 dashboard.
Vulnerabilities
Popular articles
What other people are reading right now.
How to View a Full Email Header in Outlook on the Web (Microsoft 365 / OWA)
How to View a Full Email Header in Outlook on the Web (Microsoft 365 / OWA) This guide provides instructions on how to access the full email header using Outlook on the web (also known as Outlook Web Access or OWA, typically accessed via outlook.office.com). This process is essential for diagnosing issues, verifying security settings, or checking Phished configurations. 1. Open the Target Email 1. Log in to your Outlook account via your web browser. 2. Click once on the phished simulation mail in the message list to open it in the reading pane, or double-click to open it in a new window. 2. Access the Message Source 1. Look for the More actions icon (three horizontal dots: ⋯) located in the upper-right corner of the reading pane or the message window. 2. Click the More actions icon. 3. In the dropdown menu, hover over or look for an option named View. 4. From the sub-menu, select View message details or View message source. 3. View and Copy the Full Header 1. A new window will open displaying the complete, raw content of the message, including the full email header information. This content is technical and often lengthy. 2. To copy this data for analysis or to share with support, click inside the text box, select all the text (use Ctrl+A on Windows or Cmd+A on Mac), and then copy it (use Ctrl+C on Windows or Cmd+C on Mac). 3. Click Close to exit the details window. Important Note on Phished Configuration Checks When submitting a full email header for a Phished configuration or diagnostic check, ensure you copy the entire contents of the message source window. The complete header is necessary for the support team to trace the message's journey and confirm that the required email settings and rules are correctly applied.
🖥️ Dashboard HelpCatcher security score
The Security Score in Catcher provides a quick, comprehensive view of your organization's overall security posture. It combines three key metrics into a single score ranging from 0 to 100, where higher scores indicate better security. How the Security Score Is Calculated The score is a weighted sum of three components: - Vulnerability Risk Score (VRS) – 60% weight - Behavior Risk Score (BRS) – 25% weight - Endpoint Protection Score (EPS) – 15% weight Formula Security Score = (VRS × 0.6) + (BRS × 0.25) + (EPS × 0.15) If Phished integration or ESET integration is not configured, their weights are redistributed proportionally among the remaining components to maintain a total weight of 100%. Component Breakdown Vulnerability Risk Score (VRS) Assesses the severity of vulnerabilities in your environment. - Penalty per vulnerability: - Critical: 40 - High: 20 - Medium: 5 - Low: 1 - Score normalization: Average penalty is normalized against a max of 120. - Score caps based on highest severity: - Critical: max 50 - High: max 70 - Medium: max 85 - Low: max 95 - No vulnerabilities: 100 Behavior Risk Score (BRS) Derived from the Phished integration. - If configured, score is fetched directly (0–100). - If not configured, BRS is excluded from the calculation. Endpoint Protection Score (EPS) Evaluates ESET endpoint protection and update status. Formula: EPS = ((Protected / Total) × 0.6 + (Updated / Total) × 0.4) × 100 - If not configured, EPS is excluded from the calculation. How to Improve Your Catcher Security Score Improving your Catcher Security Score means strengthening your organization's overall cybersecurity posture. Since the score is based on three components—Vulnerability Risk Score (VRS), Behavior Risk Score (BRS), and Endpoint Protection Score (EPS)—you can target improvements in each area: Vulnerability Risk Score (VRS) – 60% Weight This is the most heavily weighted component, so reducing vulnerabilities has the biggest impact. Steps to improve: - Patch critical and high vulnerabilities promptly. These carry the highest penalties. - Conduct regular vulnerability scans to identify new issues early, or do this automatically by scheduling your scans. - Implement automated patch management to reduce manual effort and delays. - Remove or isolate unused or legacy systems that may introduce risks. Behavior Risk Score (BRS) – 25% Weight This score comes from the Phished integration, which assesses user behavior around phishing threats. Steps to improve: - Enable and configure the Phished integration if not already done. - Identify and report our phishing simulations in your email client. - Train your security awareness by completing security awareness training. Endpoint Protection Score (EPS) – 15% Weight This score reflects how well your endpoints are protected and updated via ESET integration. Steps to improve: - Ensure all endpoints have ESET protection installed. - Keep endpoint protection software up to date. - Automate updates and protection checks to maintain coverage. - Monitor for unprotected or outdated devices and remediate quickly. If Integrations Are Missing If either Phished or ESET integrations are not configured, their weights are redistributed. This means the remaining components become even more critical to your score. Tip: Configuring all integrations ensures a balanced and accurate score—and gives you more control over improvements.
📷 Web application scanningHow to add header-based authentication
Configuring Session Cookie Authentication for a Web Application Scanner When you configure a web application scanner to use header authentication, you're essentially providing it with a key to an already open door. You don't need to teach the scanner how to log in; you just give it the proof of a successful login. Here's a step-by-step guide to configuring this: Get the Authentication header The first step is to get the specific header that the web application uses to authenticate requests. This is typically done after a successful login. 1. Log in Manually: Log into the web application using your browser as you normally would. 2. Open Developer Tools: Use your browser's developer tools (often by pressing F12 or Ctrl+Shift+I) to inspect network requests. 3. Inspect a Protected Request: Navigate to a page that requires authentication. In the network tab of the developer tools, select the request for that page. 4. Find the Header: In the request details, look for the headers section. The authentication token is often found in a header like Authorization , which might contain a value like Bearer <token>, or a custom header defined by the application. Copy the entire header, including the name and its value (e.g., Authorization: Bearer abc123xyz). Adding authentication to a new target 1. Click add target and select a web application scan, then click next. 2. Add your target address and other details, then check "Add authentication method". 3. Select session cookie based authentication 4. Now you can configure your authentication details 1. 1. Entrypoint URL This remains the same. It's the URL the scanner first visits. It should be a page that's only accessible after a user has authenticated. 2. Header Name and Value Instead of a "cookie name and value," you'll provide the header name and its value. The header name is typically Authorization, and the value is the authentication token. For example, the full header might look like Authorization: Bearer A1B2C3D4E5F6. In this case, Authorization is the name, and Bearer A1B2C3D4E5F6 is the value. 3. Logged In Pattern This is the same as before. It's the text or pattern the scanner looks for to confirm the session is active. It ensures the token is working as expected. 5. After filling in all the required fields (marked with an asterisk), you can click Submit to save this authentication configuration for the scan target. The web application scanner will then use this information to authenticate itself before it begins crawling and scanning the application.
📷 Web application scanningHow to add form based authentication
What is Form-Based Authentication? Form-based authentication is a common method for controlling access to a web application. It relies on a user submitting credentials, like a username and password, through a form on a login page. The server processes this information and, if the credentials are valid, it creates a user session and grants access to protected areas of the site. When you configure this for a web application scanner, you're essentially teaching the scanner how to mimic this human login process. The scanner needs to know the Login URL, the names of the input fields (Username field, Password field), and the actual Username and Password to use. By providing a Logged in pattern, you're giving the scanner a way to confirm that its login was successful, allowing it to proceed with scanning the secured parts of your application. Adding authentication to a new target 1. Click add target and select a web application scan, then click next. 2. Add your target address and other details, then check "Add authentication method". 3. Select form based authentication 4. Now you can configure your authentication details 1. Login URL*: This is the most crucial part. Enter the full URL of the login request. This is not just the login page itself, but the URL the browser posts the login form data to. You can find this using your browser's developer tools by inspecting the login form's action attribute or by watching the network traffic when you log in. 2. Logout URL: This is an optional but recommended field. Provide the full URL that logs a user out. By giving the web application scanner the logout URL, you ensure it doesn't accidentally scan this page during its normal crawl, which could interrupt the session. 3. Logged in pattern*: Enter a piece of text or a regular expression that the web application scanner should look for on a page to confirm a successful login. Examples include "Welcome, [username]", "Logout", or "My Account". This is how the web application scanner validates that its login attempt was successful. 4. Username field* and Password field*: These fields tell the web application scanner the names of the input fields on the login form. The examples username and pass are common, but you'll need to inspect the login page's source code to find the correct name attributes for the username and password fields. 5. CSRF token field: This is an optional field for applications that use a Cross-Site Request Forgery (CSRF) token. If the login form includes a hidden field for a CSRF token, you'll need to enter its name here. The web application scanner will then automatically extract and submit this token with the login request. 6. Username* and Password*: These are the actual credentials the web application scanner will use to log in. Enter a valid username and password for a test account that we can use for scanning activities. 7. Extra Form parameters: If the login form includes other hidden fields or parameters (e.g., a "Remember me" checkbox, a special identifier), you can add them here. You provide the Field name and its corresponding Value. 5. After filling in all the required fields (marked with an asterisk), you can click Submit to save this authentication configuration for the scan target. The web application scanner will then use this information to authenticate itself before it begins crawling and scanning the application.
🖥️ Dashboard HelpWhat IPs does Catcher24 use to scan my environment?
If you’re using security technologies like a Next-Gen Firewall, Intrusion Prevention System (IPS), Intrusion Detection System (IDS), or a Web Application Firewall (WAF), they may flag Catcher's traffic as suspicious and block it. We recommend allowlisting our IP ranges to avoid these problems. This article provides the full list of IP ranges you’ll need to configure in your security tools to avoid false positives or blocked traffic during scans. 95.211.123.176/28 185.24.173.0/24 FAQ Where should I add these ranges? You should add these ranges to the appropriate IPS, IDP etc. you have enabled. If your applications are hosted by a 3rd party, please inform them that you will run scans from these ranges, to avoid your 3rd party blocking our IPs. What about my firewall? If you use a perimeter firewall, please don't add our ranges to it as that would show results which aren't accessible through the internet normally.
📷 Web application scanningHow to add session cookie authentication
Session Cookie Authentication 🍪 Session cookie authentication is a method where a client proves its identity by presenting a valid session cookie to the server. This cookie is a small piece of data that the server sends to the client after a successful login. It acts as a token that identifies the user's session, so the user doesn't have to re-enter their credentials on every page request. The server uses this cookie to determine the user's logged-in state and associated permissions. Configuring Session Cookie Authentication for a Web Application Scanner When you configure a web application scanner to use session cookie authentication, you're essentially providing it with a key to an already open door. You don't need to teach the scanner how to log in; you just give it the proof of a successful login. Here's a step-by-step guide to configuring this: Get the Session Cookie The most crucial step is to obtain a valid session cookie from an active, logged-in session. To do this, you'll need to manually log in to the web application using your browser. Once logged in, use your browser's developer tools (often accessible by pressing F12) to inspect the network requests. Look for a request to a protected page and find the Cookie header. This header contains the session cookie and any other cookies the application is using. Copy the entire cookie string. Adding authentication to a new target 1. Click add target and select a web application scan, then click next. 2. Add your target address and other details, then check "Add authentication method". 3. Select session cookie based authentication 4. Now you can configure your authentication details 1. Entrypoint URL*: This is the URL that the web application scanner will first visit when it begins crawling the application. It's often a page that requires authentication, such as the user's dashboard or profile page, to ensure the provided cookie is valid from the start. 2. Cookie Name and Value: Paste the cookie string you copied from the browser's developer tools here. Some scanners might require you to provide the cookie's name and value separately, while others may accept the entire string. For example, a cookie might look like JSESSIONID=A1B2C3D4E5F6. In this case, JSESSIONID is the name and A1B2C3D4E5F6 is the value. 3. Logged In Pattern: Just like with form-based authentication, you'll need to provide a logged in pattern. This is a piece of text or a regular expression that the scanner will look for on a page to confirm that the cookie is still valid and the session is active. Examples could be "My Account," "Logout," or "Welcome, [username]." 5. After filling in all the required fields (marked with an asterisk), you can click Submit to save this authentication configuration for the scan target. The web application scanner will then use this information to authenticate itself before it begins crawling and scanning the application.