We scanned the public infrastructure attached to example-gmbh.ch and found 14 issues across 5 exposed services. Two findings are critical and need attention within the next few days. The most serious issue is an outdated Microsoft Exchange server that has not received a security update since May 2024, which is actively targeted by automated attacks on the internet.
The rest of this report explains each finding in plain language. Every finding has a severity rating, a short explanation of what it means, why it matters for your business, and how to fix it. If you forward this report to your IT provider, they will have everything they need to act.
What we found: Your Exchange server at mail.example-gmbh.ch (203.0.113.42) is running Exchange Server 2016 CU23 without the November 2024 security update. The build number responds as 15.1.2507.27.
Why it matters: CVE-2024-21410 allows an attacker to relay NTLM credentials to your Exchange server and impersonate any user, including administrators. Working exploits have been public for over a year. Automated scanners hit every Swiss IP with exposed Exchange multiple times per day looking for this exact vulnerability. A successful attack gives the attacker access to every mailbox on the server and usually serves as the entry point for ransomware deployment on the rest of your network.
How to fix: Install Exchange Server 2016 CU23 Nov24SU or later from the Microsoft download center. Before applying, back up the server and take a snapshot. The update takes 30 to 60 minutes and requires a restart of the Exchange services. If you cannot patch immediately, restrict access to Outlook Web Access by IP (allow only your office network) through your firewall as a temporary measure.
What we found: Exchange Server 2016 is no longer receiving security updates from Microsoft. The server at mail.example-gmbh.ch is 6 months past the last available security patch.
Why it matters: Every new vulnerability discovered in Exchange 2016 from now on will remain unpatched on your server permanently. Attackers actively monitor end-of-life software because it becomes a guaranteed target. If your Exchange server is your primary mail infrastructure, it will be compromised eventually, not maybe.
How to fix: Plan a migration to Exchange Server Subscription Edition (SE) or to Microsoft 365. For SMBs, Microsoft 365 Business Standard at CHF 12 per user per month is almost always the right choice: mail moves to Microsoft's infrastructure, you stop running Exchange yourself, and the on-prem server can be decommissioned. Budget 2 to 4 weeks for the migration with your IT provider.
What we found: Port 3389 on 203.0.113.42 is open and accepting RDP connections. The service banner identifies Windows Server 2019.
Why it matters: RDP on the public internet is the most common entry point for ransomware targeting SMBs. Attackers use automated tools to guess passwords at a rate of thousands per second. Even with a strong password, exposure to the full internet means every CVE that affects RDP affects your server. Multiple major ransomware groups including LockBit and BlackCat explicitly look for exposed RDP as their preferred initial access method.
How to fix: Close port 3389 on your firewall immediately. For administrators who need remote access, route RDP through a VPN (WireGuard or OpenVPN) or a Zero Trust service (Tailscale, Cloudflare Access). If you must keep RDP exposed temporarily, enable Network Level Authentication, set account lockout at 5 failed attempts, and add a rate limit on the firewall.
What we found: A MongoDB 4.4.18 instance is listening on 203.0.113.42:27017 and accepts connections without any authentication. We did not enumerate the contents (our scan stops at the first credential check).
Why it matters: Anyone on the internet can connect to this database, read all of its data, and delete or modify it. Open MongoDB instances are routinely found and deleted by extortion bots: the entire database gets wiped and replaced with a ransom note demanding cryptocurrency for the backup the attacker already made. If this database contains customer data, you may have a reportable data breach under Swiss FADP.
How to fix: First, bind MongoDB to localhost only by setting bindIp: 127.0.0.1 in /etc/mongod.conf and restarting the service. Then enable authentication by uncommenting the security.authorization: enabled line and creating an admin user. If the database was exposed for any length of time, assume it was accessed and notify your data protection officer.
What we found: The SSH service on port 22 is running OpenSSH 7.4 (CentOS 7 default). Current stable is OpenSSH 9.9. Your version is affected by CVE-2023-38408 and CVE-2024-6387 (regreSSHion).
Why it matters: CVE-2024-6387 allows remote unauthenticated attackers to execute code as root on the server under the right timing conditions. Glibc-based Linux distributions are vulnerable. Exploitation is difficult but demonstrated. OpenSSH 7.4 is also missing several mitigations present in modern versions.
How to fix: CentOS 7 is itself end-of-life as of 30 June 2024. The long-term fix is to migrate this server to AlmaLinux 9, Rocky Linux 9, or Ubuntu 22.04 LTS. As an interim, you can backport the OpenSSH fix by building from source, but this is not a durable answer. Plan the OS migration within the next quarter.
What we found: Your mail server still accepts TLS 1.0 and TLS 1.1 connections on port 443. Modern clients should only use TLS 1.2 and above.
Why it matters: TLS 1.0 and 1.1 have multiple known weaknesses (BEAST, POODLE) and are explicitly prohibited by PCI-DSS and deprecated by all major browsers. In a compliance audit this is a finding. In a phishing scenario, an attacker who can intercept traffic can downgrade the connection and read it.
How to fix: On IIS, open Internet Information Services Manager, select the server, go to Schannel protocols in the registry editor (HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols) and disable TLS 1.0 and 1.1 by setting Enabled = 0 and DisabledByDefault = 1. Reboot the server. Re-test with sslscan mail.example-gmbh.ch.
What we found: https://www.example-gmbh.ch/server-status returns the Apache mod_status page, which reveals internal details: active requests, client IPs, referrers, worker processes, and URL paths currently being served.
Why it matters: This is not an immediate compromise, but it gives an attacker a live view of your traffic and internal paths that should not be public. It often reveals admin URLs, session tokens in query strings, and user-agent patterns useful for targeted attacks.
How to fix: In your Apache config (usually /etc/apache2/mods-enabled/status.conf), restrict access to localhost only: <Location /server-status> Require ip 127.0.0.1 </Location>. Reload Apache. Verify by requesting the URL from the public internet and confirming a 403 response.
What we found: The IPsec VPN on 203.0.113.43 uses a 1024-bit DH group for key exchange. Current practice is 2048 bits or higher, or switching to elliptic curve groups.
Why it matters: 1024-bit DH has been considered breakable by nation-state actors since 2015 (Logjam research). A well-resourced attacker who captures VPN traffic could decrypt it with sufficient computing time. For most SMBs this is not an urgent threat, but it is a finding a cyber insurance questionnaire or ISO audit will flag.
How to fix: Reconfigure your VPN gateway to use DH group 14 (2048 bits) or group 19/20 (elliptic curve) as the minimum. For pfSense, Fortigate, and Sophos XG the setting is typically under IPsec phase 1 proposals. Remove group 2 (1024 bit) from the allowed list.
What we found: Your main website is missing Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy headers.
Why it matters: These headers are defense-in-depth against cross-site scripting and clickjacking attacks. Their absence alone is not exploitable, but combined with any bug in your website they can escalate an attacker's options.
How to fix: Add the following to your Apache or nginx configuration and reload: Content-Security-Policy: default-src 'self', X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin. Test with securityheaders.com.
What we found: https://www.example-gmbh.ch does not send the Strict-Transport-Security response header.
Why it matters: Without HSTS, a visitor's first connection can be downgraded to HTTP by an attacker on the same network (public Wi-Fi, for example). HSTS tells browsers to always use HTTPS for your domain, even on the first request.
How to fix: Add Strict-Transport-Security: max-age=31536000; includeSubDomains to your HTTPS responses. Start with a shorter max-age (86400, one day) while you verify that everything on your domain uses HTTPS, then raise it.
What we found: The internal application portal uses a self-signed certificate that is not trusted by browsers or operating systems.
Why it matters: Self-signed certificates train your users to click through security warnings, which undermines their ability to recognize real phishing attempts later. For any service that holds credentials, a trusted certificate is expected.
How to fix: Issue a free certificate from Let's Encrypt using certbot, or use your existing domain certificate (SAN/wildcard) if you have one. If the service is only reachable on an internal network, set up an internal certificate authority and distribute the root CA to your managed devices.
What we found: Your web server responds with Server: Apache/2.4.52 (Ubuntu) in every HTTP response.
Why it matters: Version disclosure does not enable an attack on its own, but it removes a guess for attackers scanning for vulnerable versions. An attacker querying exploit databases can check for CVEs targeting your exact version without probing you first.
How to fix: In Apache, set ServerTokens Prod and ServerSignature Off in the main config file. Reload Apache. The Server header will then only contain the string Apache.
What we found: Your domain does not have an SPF DNS record.
Why it matters: SPF tells the world which servers are allowed to send email for your domain. Without it, anyone can spoof mail as @example-gmbh.ch, and other mail servers have no way to reject it. This is a top cause of successful phishing attacks against your suppliers and customers.
How to fix: Add a DNS TXT record at example-gmbh.ch: v=spf1 include:spf.protection.outlook.com -all (adjust the include depending on your mail provider). After 24 hours, verify with a tool like mxtoolbox.
What we found: No DMARC DNS record at _dmarc.example-gmbh.ch.
Why it matters: DMARC builds on SPF and DKIM to tell receiving mail servers what to do with mail that fails authentication. Without it, spoofed mail may still be delivered to recipients' inboxes. DMARC also gives you reports on who is trying to send mail as your domain, which is useful for spotting active phishing campaigns.
How to fix: Add a DNS TXT record at _dmarc.example-gmbh.ch: v=DMARC1; p=quarantine; rua=mailto:dmarc@example-gmbh.ch. Start with p=none for monitoring, review the reports for two weeks, then move to p=quarantine and eventually p=reject.
If you subscribe to the Business tier, this scan runs every week and we tell you which findings are new, which are fixed, and which are still open. You can share the dashboard with your IT provider and track progress over time.
Run a free scan on your home network, or book a 15 min call to scan your company.
