The build posts show how a network should look. This is what they usually look like when nobody's checked — an anonymised write-up of a security audit across three small family hotels sharing one part-time IT contact. No breach, no drama; just an hour of scanning that turned "our Wi-Fi is fine" into a two-page findings list, and the one finding that would have cost them a GDPR incident.
Conducted under a signed engagement with written scope. Client, addresses, and identifying details are changed or generalised; the findings are representative of the real ones, not a copy. Shared with permission. The point is the pattern — because it's the same pattern in most small hospitality networks.
Three small hotels, same owner group, same story as thousands of others: the network grew by whoever was cheapest that year, and "security" meant a Wi-Fi password. They booked the audit because a booking platform asked whether their guest data was "segmented" and nobody knew what the honest answer was. The honest answer was no.
An audit like this isn't a red-team engagement — it's a structured look at exposure and configuration, the defensive mirror of Attacking MikroTik Gear and Attacking Cisco Gear. You look at what's reachable, what's default, what's flat, and what would happen if one guest laptop turned hostile. Most of the value is found in the first hour; the rest is writing it up so the owner can act on it. Here's what that hour surfaced.
01
Before any clever testing, you map what's there. A single sweep of each site's LAN told the whole story: one subnet, everything on it, nothing between anything.
# Connected to guest Wi-Fi. One /24, and everything answers on it: $ nmap -sn 192.168.0.0/24 192.168.0.1 router (MikroTik) 192.168.0.10 RECEPTION-PC # the booking / PMS terminal 192.168.0.23 NVR-LOBBY # camera recorder 192.168.0.41 guest laptop (me) 192.168.0.55 BOOKING-BACKUP # a NAS with... everything # No VLANs. A guest device is a peer of the booking PC and the cameras.
Guest, staff, payment, and CCTV traffic all shared one broadcast domain at every site. The Wi-Fi password kept strangers off the internet link; it did nothing to stop a guest — or malware on a guest's device — from reaching the machine that processes bookings and card details. This is the finding under the booking platform's question, and the reason guest Wi-Fi needs its own network. Remediation: VLAN segmentation with default-deny between zones — the design from the hotel build note.
02
The next look is always the router itself. At the two MikroTik sites, the management surface was reachable and the versions were old — the exact combination the offensive post warns about.
| What we found | Why it's a finding |
|---|---|
| Winbox reachable from the WAN | Management plane exposed to the internet — the root cause of every mass RouterOS compromise (High) |
| RouterOS two+ years behind | Known CVEs apply to an exposed service (High) |
Default admin, weak password | No exploit needed to take the router (Critical at one site) |
| No off-box logging | A compromise would be invisible; local logs are wiped on reboot (Medium) |
| Bandwidth-test server on | DoS and brute-force surface left enabled (Low) |
None of this needed new hardware. It needed the Securing RouterOS checklist: a default-drop input firewall so Winbox is unreachable from the WAN, an upgrade (packages and firmware), named accounts with strong passwords, the default admin gone, leftover services off, and remote syslog pointed at a cheap collector. Half a day per site, and the internet-facing attack surface went to effectively zero.
03
Every audit has a headline finding — the one that turns an abstract report into a decision. Here it was the straight line from the guest Wi-Fi to the machine holding passport and card details.
Because everything shared one subnet, a guest device could open the booking PC's file shares and reach the NAS labelled BOOKING-BACKUP — which held, in plain folders, scanned passports, card-payment records, and years of reservation exports. No authentication challenge worth the name, no network boundary in the way. A single guest with a compromised laptop, or simply a curious one, was one click from a reportable personal-data breach under GDPR — with the fines and the notification duty that follow.
This is the finding owners actually feel, because it's not "your config is untidy" — it's "a guest can reach the passports." The fix is the same segmentation from Finding #1 plus tightening the NAS itself (authentication, no anonymous shares, encryption at rest). Framed in business terms — regulatory exposure, not packet diagrams — it's also the finding that got the whole remediation approved that afternoon.
04
Findings are worthless if the person paying can't act on them. The deliverable was written for the owner first and the IT contact second — severity, plain-language impact, and a fix per item.
The report ranked every finding by real risk, said what each one meant in terms a hotelier understands ("a guest can reach the booking computer"), and gave a concrete remediation with an effort estimate. Nothing in it required a forklift upgrade — segmentation on the existing MikroTiks, a hardening pass, an upgrade, and locking down the NAS. We re-tested after the fixes and issued a short verification note the owner could show the booking platform. That verification note, not the findings list, was what they'd actually asked for without knowing it.
Nothing here was exotic. Flat network, exposed management, weak credentials, sensitive data reachable from the guest side — it's the same four findings in most small hospitality networks, and each maps to a fix already written up in these posts. The audit's value isn't discovering something novel; it's finding the ordinary problems before someone else does, and translating them into decisions the owner can make.
Takeaways
NOCTIS runs practical security audits for hotels, villas, and businesses across Crete — exposure, segmentation, and data-reachability checked and written up in plain language, with a fix-first report and a re-test you can show your partners.
Book a Discovery Call →