Case File: The Network That Had Been Open for Eight Months

The Brief

The client was a mid-sized hospitality group operating three properties across two atolls. Around ninety staff, a central office in Malé, a property management system tied to an online booking engine, and a finance team that processed everything from supplier invoices to payroll on a shared internal network.

Their new General Manager had come from a larger group. She'd seen what proper IT governance looked like. What she inherited did not look like that. Two weeks into the role, she asked for an external audit before committing to any new technology spend.

We said yes. We expected to find the usual: weak passwords, outdated firmware, a few unpatched machines, maybe a misconfigured firewall rule or two.

We found all of that. We also found something we weren't expecting.

What a Network Audit Actually Looks Like

An audit isn't a scan. A scan is one step in an audit.

We started where we always start: documentation review. Network diagrams, asset registers, firewall policy exports, DHCP logs, any records of previous IT work. The hospitality group had a folder in a shared drive labelled "IT." It contained three documents. One was a Wi-Fi password list from 2021. One was a scanned receipt for a UPS unit. The third was a photo of a server rack, taken on a phone, slightly blurred.

That told us everything we needed to know about the state of institutional IT knowledge in this organisation. Not blame, just baseline.

We moved to physical inspection. The server room was a repurposed storage closet on the second floor of the Malé office, shared with cleaning supplies. The rack had a core switch, two access layer switches, a router provided by the ISP, a Windows Server 2016 box running as both domain controller and file server, and a consumer-grade NAS that someone had zip-tied to the side of the rack.

The server had not been restarted in four hundred and twelve days.

The Scan

Active reconnaissance came next. We ran internal network scans across all three VLAN segments, mapped live hosts, identified open ports and running services, and fingerprinted operating system versions.

The results took thirty minutes to run and about two hours to absorb.

Guest Wi-Fi and the staff operational network were on the same physical VLAN. There was no segmentation. A guest sitting in the lobby with a laptop could, in principle, reach the file server. In practice, one of them already had.

Buried in the DHCP lease history, which the router had been logging silently for the better part of a year, was a sequence of internal IP assignments that didn't match any registered device. The MAC address vendor prefix resolved to a network adapter manufacturer common in cheap embedded devices. The lease timestamps showed activity in short, regular bursts: late evenings, mostly. The first entry was eight months ago.

Someone had been on this network, quietly, for eight months.

Going Deeper

We pulled the firewall logs. The ISP router had basic logging enabled but nowhere to send the logs, so they'd been accumulating in local memory and rotating out every thirty days. What remained showed outbound connections from that unrecognised internal IP to two external addresses. Both resolved to hosting infrastructure in a jurisdiction with no data sharing agreements and a well-documented history of hosting command-and-control servers for opportunistic malware campaigns.

The device was no longer on the network when we scanned. It had last appeared eleven days prior.

We didn't know exactly what had been taken, accessed, or staged. We did know that an unidentified device had spent eight months with unrestricted internal network access, and had been communicating with infrastructure that had no legitimate business purpose.

We briefed the General Manager that afternoon. She asked three questions. The first was whether guest data had been compromised. The second was whether they had an obligation to notify anyone. The third was whether we could fix it.

The answers were: possibly, yes, and yes.

The Remediation

We worked in order of risk.

Network segmentation was the most urgent structural fix. The guest network was isolated onto its own VLAN with a deny-all rule preventing any lateral access to internal resources. Staff devices were moved to a separate segment, with the property management system placed on a third restricted VLAN accessible only from specific authorised workstations. A proper next-generation firewall replaced the ISP router as the perimeter device, with outbound filtering, application awareness, and centralised logging to a syslog server we stood up in the server room.

The unrecognised device's MAC address was blacklisted across all access points. It never came back.

The file server was forensically imaged before anything else was touched, preserving the state of the system at the time of discovery. We reviewed access logs on the shared drives and found evidence of bulk enumeration: directory listings across the finance and operations folders, accessed from that internal IP, at times when no staff were in the office. Files had been read, not modified. The most likely scenario was reconnaissance and exfiltration, not destruction.

The server was patched, hardened, and had its roles separated. Domain controller functions moved to a dedicated virtual machine. File server functions remained on the physical host, now with audit logging enabled on every sensitive directory.

All domain user passwords were reset in a single coordinated window. Every service account was reviewed. Three accounts that belonged to former staff were still active. They were disabled.

The consumer NAS, which had been running with default credentials and no encryption, was replaced with a properly configured backup appliance with immutable snapshot support and access restricted to the backup service account only.

The Notification Question

The General Manager was right to ask.

Maldivian data protection obligations are still maturing, but the hospitality group processed payment card data through a third-party gateway. That put them inside the scope of PCI-DSS. A potential compromise of the cardholder data environment, even an unconfirmed one, carries its own notification and forensic investigation requirements.

We helped them engage the right legal and compliance contacts. We prepared the technical summary they needed to have that conversation. What happened after was between them and their obligations.

We don't write that part of the story for clients. We just make sure they understand it exists.

What the Audit Was Actually For

At the end of the engagement, we presented findings across forty-one controls: network architecture, access management, endpoint security, backup and recovery, logging and monitoring, physical security, and vendor access. Eleven findings were rated critical. Sixteen were high. The rest were medium and low, the kind of hygiene issues every organisation accumulates over time.

The General Manager read the report over a weekend and came back on Monday with a question we don't hear often enough.

"How did we get here without anyone noticing?"

The honest answer is that nobody was looking. The previous IT arrangement had been a part-time contractor who kept things running and asked no harder questions than necessary. The systems did what they were asked to do. Nothing had visibly failed. When nothing visibly fails, most organisations conclude nothing is wrong.

But systems don't announce their own vulnerabilities. Networks don't send alerts about the access policies they weren't configured to enforce. An unknown device on your network doesn't introduce itself.

That is precisely why you have to go looking.