Endolum Sentinel · Sample report
An outside view of your public infrastructure.
example-gmbh.ch
Scan on April 20, 2026
Summary
Sentinel checked the public infrastructure of example-gmbh.ch and found 7 grouped issues across 5 exposed services. Two findings need immediate attention: a Microsoft Exchange server past end of support, and a database reachable from the internet without a password.
Verdict
Your Exchange server has lost vendor support and your database is exposed without a password. Both are actively targeted by automated attacks. Contact your IT provider today.
This sample is generated from a real Sentinel scan against a synthetic target. Hostnames, IP addresses and identifiers are anonymized. Severity, evidence and remediation steps mirror the format of a paid Sentinel report.
Endolum GmbH · Oberdorfstrasse 8, 8853 Lachen SZ · CHE-297.991.738 · endolum.io
Findings
Critical
Microsoft Exchange Server 2013 is past end of support
Your mail server at mail.example-gmbh.ch runs Exchange Server 2013. Microsoft ended support in April 2023. Every Exchange 2013 vulnerability disclosed since then remains permanently unpatched on this server.
Risk
Automated attacks scan every Swiss IP with exposed Exchange several times per day. A successful attack reaches every mailbox and is typically the first step before ransomware is deployed across the internal network. Cyber insurance policies commonly deny claims when end-of-life software is the root cause.
Fix
Plan the migration off Exchange 2013 within the next few weeks. For most SMBs, the practical answer is moving to Microsoft 365. Your IT provider can scope and run the migration.
Technical fix
Target: Microsoft 365 Business Standard or Exchange Server SE. Path: stand up the M365 tenant, enable Azure AD Connect or Entra Cloud Sync, migrate mailboxes in waves via EAC or a third-party tool, cut over MX records, retire the on-prem server. Budget 2 to 4 weeks end to end.
Evidence
OWA at https://mail.example-gmbh.ch/owa/ returns X-OWA-Version: 15.0.1497.2. Last available Exchange 2013 security update: May 2023.
High
MongoDB database on port 27017 is open without authentication
A MongoDB database accepts connections from the public internet without requiring a password. Anyone who finds the port can read, modify, or delete every document in it.
Risk
Open MongoDB instances are routinely found and wiped by extortion bots. If the database holds customer or staff data, any unauthorized access is a reportable incident under the Swiss FADP. The exposure itself creates regulatory risk.
Fix
Close port 27017 at the firewall today and require a password for connections. Your IT provider can bind the database to localhost and enable authentication during the next maintenance window.
Technical fix
In /etc/mongod.conf set net.bindIp: 127.0.0.1 and security.authorization: enabled. Create an admin user: use admin; db.createUser({user: 'admin', pwd: '<strong>', roles: ['root']}). Restart mongod. Block inbound 27017/tcp from all external addresses at the firewall.
Evidence
TCP 27017 open on 203.0.113.42. MongoDB 4.4.18. isMaster returned ok: 1 with no credentials.
High
Remote Desktop (RDP) is reachable from the internet
Port 3389 on your server is reachable from the public internet. Internet exposed RDP is by far the most common entry point for ransomware against Swiss SMBs.
Risk
Automated password guessing hits exposed RDP several thousand times per hour. Even with a strong password, every new Windows vulnerability that touches RDP affects your business. A successful compromise typically leads to ransomware encryption within 24 hours.
Fix
Remove Remote Desktop from the public internet this week. Route administrative access through a VPN or Zero Trust service. Your IT provider can complete this in a few hours.
Technical fix
Block 3389/tcp at the perimeter firewall. Options for admin access: WireGuard or OpenVPN site to site, Tailscale, Cloudflare Access with service tokens, or RDP Gateway with MFA. If short-term exposure is unavoidable: enable NLA, set account lockout at 5 attempts for 30 minutes, add per-source IP rate limiting.
Evidence
TCP 3389 open on 203.0.113.42. Banner: Microsoft Terminal Services. TLS 1.2 with certificate CN=SERVER01.example-gmbh.local (self-signed).
Medium
Outdated TLS versions accepted on mail and web server
Your mail server and your website both accept TLS 1.0 and TLS 1.1 connections. Both versions have known weaknesses and are no longer considered secure. Modern clients already prefer TLS 1.2 or 1.3.
Risk
An attacker on the same network as a staff member (public Wi-Fi, compromised router) can downgrade the connection to the older version and read the traffic. Compliance audits and cyber insurance questionnaires regularly flag this.
Fix
Have your IT provider disable TLS 1.0 and 1.1 on both servers. End-user impact is minimal since modern clients already use TLS 1.2 or 1.3.
Technical fix
IIS: set HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server Enabled=0 and DisabledByDefault=1 (same for TLS 1.1). Reboot. nginx: ssl_protocols TLSv1.2 TLSv1.3; then nginx -s reload. Verify with sslscan mail.example-gmbh.ch and sslscan www.example-gmbh.ch.
Evidence
mail.example-gmbh.ch:443 accepts TLSv1.0 (RSA-AES128-SHA). www.example-gmbh.ch:443 accepts TLSv1.1.
Low
Security headers missing on www.example-gmbh.ch
Your website does not send several HTTP response headers that browsers use to contain damage if something on the page misbehaves. Since the site has no login forms or user input, the practical risk is low.
Risk
Missing headers do not let an attacker in. If a bug on the site ever allowed code injection, these headers would limit what the attacker could do.
Fix
Have your IT provider add the standard set of security headers to the web server. 15 minutes of work, no functional impact on the site.
Technical fix
In the nginx server block (or Apache equivalent) add: add_header Content-Security-Policy "default-src 'self'" always; add_header X-Frame-Options DENY always; add_header X-Content-Type-Options nosniff always; add_header Referrer-Policy strict-origin-when-cross-origin always; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always. Reload nginx. Verify on securityheaders.com.
Evidence
GET https://www.example-gmbh.ch/ response is missing Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Strict-Transport-Security.
Low
Web server version exposed in HTTP responses
Every response from your website includes a header that reveals the exact software version. Attackers scanning for vulnerable versions read this header to prioritize targets.
Risk
Version disclosure alone breaks nothing. It does land your address on automated target lists faster the moment any new vulnerability is published for that specific version.
Fix
Have your IT provider hide the detailed server version in response headers. Small change, no end-user impact.
Technical fix
Apache: set ServerTokens Prod and ServerSignature Off in the main config and reload. nginx: server_tokens off; in the http block and reload. Verify with curl -sI https://www.example-gmbh.ch shows Server: Apache or Server: nginx without a version.
Evidence
HTTP/1.1 200 OK response header: Server: Apache/2.4.52 (Ubuntu).
Info
Spoofing protection missing for example-gmbh.ch
Your domain publishes neither an SPF nor a DMARC record. These DNS records tell other mail servers which systems may send as @example-gmbh.ch and what to do with messages that fail the check.
Risk
Without these records, anyone can send mail that looks like it comes from your domain. Staff, clients, and suppliers can be phished with convincing forged messages. Your legitimate outgoing mail also lands in spam folders more often.
Fix
Have your IT provider add an SPF record and a DMARC record. 10 minutes of configuration plus DNS propagation time.
Technical fix
SPF: TXT record at example-gmbh.ch: v=spf1 include:spf.protection.outlook.com -all (adjust the include value to match the actual mail provider). DMARC: TXT record at _dmarc.example-gmbh.ch: v=DMARC1; p=quarantine; rua=mailto:dmarc@example-gmbh.ch. Start with p=none for two weeks, review aggregate reports, then tighten to p=quarantine and finally p=reject.
Evidence
dig TXT example-gmbh.ch returns no v=spf1 record. dig TXT _dmarc.example-gmbh.ch returns NXDOMAIN.
Next steps
- Forward this report to your IT provider today. Ask them to start the Exchange migration and close the open MongoDB port immediately.
- This week, confirm that Remote Desktop has been removed from the public internet and replaced with VPN or Zero Trust access.
- Within a month, disable TLS 1.0 and 1.1 on all servers and add the standard security headers to the website.
- Before your next audit or cyber insurance renewal, publish SPF and DMARC records and hide the web server version.
- Subscribe to Sentinel Business so weekly rescans show what is new, fixed, or back.