Case Study · Incident Response - Engave S.A.
How we restored Wi-Fi at a large hotel property with no administrative access, preserving evidence and locking down the environment after the incident
Incident at a glance
Facility
A large hotel (approx. 200 rooms plus common areas) with an infrastructure of 250 access points and around 20 switches, managed centrally through UniFi
Report
February 11, 8:30 PM - complete Wi-Fi outage across the entire property
Complication
No administrative passwords to key infrastructure components - Engave was taking over service and there was no controlled environment handover
Root cause
A deliberately introduced conflict in the RADIUS configuration - triggered a gateway provisioning loop, blocking all network traffic
Recovery
February 12, 7:00 PM - full restoration of Internet and Wi-Fi across the entire property
Context
When Wi-Fi goes down at a large hotel property, guests first notice the lack of Internet in their room. But that's only the visible layer of the problem. In a modern hotel, the same network environment runs the BMS - the Building Management System - which controls heating, air conditioning, ventilation, and optimal energy consumption. A network failure means losing control over room temperature, ventilation units, and conditions in the spa and pool areas.
The front desk gets flooded with complaints it can't resolve - because the tool it needs is out of reach.
That was the exact scenario that night. With one extra complication: Engave was in the process of taking over IT service for the property. The previous administrator hadn't handed over passwords, documentation, or an account list. We started from zero - in the middle of an active incident.
The biggest problem: no access to anything
A factory reset would have been the fastest way to regain control of the devices. But it would also have destroyed the logs - the only evidence of what happened and who did it. We deliberately ruled it out.
The only reliable foothold was the mailbox. The client had the hosting password for the mail account - that was enough. We changed the password on the mailbox linked to the previous administrator's account and triggered the password recovery procedure for the UniFi panel. The reset link landed in that mailbox - we regained access to the controller.
An added technical complication: the UniFi controller only had an Internet connection for 1-3 seconds at a time before it dropped - a classic symptom of a flapping interface. Resetting the password through the cloud console didn't change the password locally on the device. We had to time our actions to that few-second connection window to sync the passwords from the cloud console and gain access from the internal network.
It worked.
What the logs revealed: traces of deliberate actions
Once we gained access to the UniFi logs, we could reconstruct the sequence of events. The logs showed that an account with a 'First Name Last Name' structure had made remote modifications in areas that directly affect the operation of the entire network infrastructure.
Three categories of changes were especially significant:
RADIUS is the mechanism that determines who can access the network, and under what conditions. Changes at this layer can create hidden access paths that are hard to detect through standard configuration checks.
Modifications like this can cut devices off or reroute network segments into a different zone - for example, merging the guest network with the internal network. In this case, one side effect was loss of access to the BMS system.
This was a deliberate act with a clear purpose: eliminate any quick path back to the previous configuration and make root-cause investigation harder. Without logs and without a backup, an incident like this becomes far harder to explain and fix.
The biggest risk factor wasn't technology. It was process - or rather, the lack of one. A single administrator with full privileges, without a controlled offboarding process, can bring critical services for an entire property to a halt. And can do it in a way that makes recovery as difficult as possible.
Diagnosis: provisioning loop
The symptom present in the UniFi panel from the start of the incident was the message: 'Gateway configuration changes could not be applied.' The Internet gateway was receiving configuration from the controller but couldn't deploy it. The alert kept reappearing at short intervals - a classic sign of a loop.
The cause was precisely hidden. In the RADIUS configuration area, an additional element named 'system' had been created - while one with that name already existed. This created a duplicate that triggered a conflict. The controller kept broadcasting a configuration the gateway couldn't correctly apply - and it fell into a loop of repeated attempts, none of which ever completed.
Result: the entire hotel without Internet and Wi-Fi for 22.5 hours.
The fix required precision: not deleting the problematic entry (which would have erased the trace in the logs), but renaming it - from 'system' to 'system1'. The conflict disappeared. The configuration was broadcast correctly. The gateway broke out of the loop, initialized properly, and Wi-Fi came back online. In parallel, the original VLAN configuration was restored - recovering access to the BMS system as well.
Incident timeline
Ticket: complete Wi-Fi outage across the entire hotel property.
Regaining access to the UniFi controller via the password reset procedure on the email account. Parallel inventory of the environment and search for any remaining access points.
Log analysis. Identification of the RADIUS configuration conflict as the root cause. Confirmation of traces of deliberate configuration changes made by an external account.
Removal of the conflict (renaming the duplicate without erasing traces). Full restoration of internet and Wi-Fi. Restoration of VLAN configuration - regained access to the BMS.
Immediate security actions: enabling backup, deploying MFA, disabling accounts linked to the previous administrator, and cleaning up cloud access.
Results
22.5h
complete loss of Wi-Fi and BMS in a large hotel property - restored without losing logs or evidence
3 sec.
the connection window we had to time perfectly to regain access to the infrastructure
0
pieces of evidence lost - infrastructure restored without a factory reset, logs preserved in full
The hotel regained working Wi-Fi, a working BMS, and full control over its infrastructure. But more important than the speed of recovery is what was preserved: logs with the complete sequence of events, documenting what happened and who did it.
After the incident, the environment was immediately locked down: configuration backup re-enabled, MFA made mandatory for all administrative panels, accounts linked to the previous administrator disabled, and cloud access cleaned up. The typical 'someone comes back later because they still have access' vector was closed.
Lesson: offboarding is a security procedure
This incident is an extreme example of the consequences of skipping controlled offboarding. One person with full privileges over the network infrastructure - without a handover procedure at the end of the engagement - can effectively shut down a property. And can do it in a way that makes recovery as difficult as possible: disabling backups, disabling logs, and making changes in places that aren't obvious at first glance.
Recommended checklist for offboarding a person responsible for IT:
Wi-Fi controllers, firewalls, switches, cloud panels, email accounts linked to the infrastructure.
VPN, administrative panel access, and accounts in network management systems.
Removal of redundant accounts, verification of remaining permissions. MFA for all administrative panels, without exception.
A copy of the configuration stored off-device, with correctness confirmed. Who logged in remotely, when, and what changes they made - even before the engagement formally ended.
What this means for your property
Incidents like this don't require a sophisticated attack. They only require one person with privileges that nobody revoked. That's why an offboarding procedure is just as important as a firewall - because no firewall blocks someone who has a valid administrator password. If you want to know how access security looks in your infrastructure, we start with one conversation.
engave.pl/kontakt
Engave S.A. · engave.pl · All rights reserved
Cybersecurity, IT care, digitalisation - whatever the topic, we're happy to talk. Describe your need and the right specialist will get back to you within 24 business hours.
CONTACT:
biuro@engave.pl
+22 863 13 90
Technical support: +48 604 470 151
16 Czarodzieja St., 03-116 Warsaw, Poland