Think the BAS Has Been Compromised? The First Hour

Most of the time, when the building does something strange, it's a sequence bug, a failed sensor or someone with an operator login who didn't tell anyone. But occasionally it isn't. And the instincts that serve us well on a normal service call — reboot it, reload it, get it running again — are exactly the wrong ones when someone else has been in the system.

This article is the first hour: what to look for, what to do first, and what not to do. It's written for the technician who's on site or on the phone when the call comes in. The owner's IT or security team runs the investigation; your job is to keep the building safe and not destroy the evidence they'll need.

Signs worth taking seriously

None of these proves a compromise on its own. Any of them is worth pausing on before you "fix" it.

• Setpoints, modes or overrides changing unexpectedly, especially out of hours, and especially if the audit log shows no user making the change or shows a user who says they didn't.
• Accounts you don't recognise on the supervisor or a controller, or known accounts with new privileges.
• Schedules altered across many systems at once, or set to values nobody would choose.
• Ransom notes, strange files or encrypted file names on the supervisor, or the BAS software suddenly unable to open its database.
• Remote sessions nobody arranged — a remote-access log showing a connection at 3 a.m., or a remote-desktop tool showing an active session.
• Devices disappearing or new devices appearing on the BAS network, or controllers restarting without a power event.
• Passwords that suddenly don't work for several people at once.

Priority one: life safety and equipment safety

Before anything else, make sure people and plant are safe. A building control system can do physical harm: a boiler held at high fire, a chiller run without flow, freeze protection disabled, pressurisation fans changed, an isolation room's airflow reversed.

• Life-safety systems — fire alarm, smoke control, stair pressurisation — are normally separate and listed systems. Confirm with the owner that they're operating normally; if there's any doubt, involve the fire alarm contractor and follow the site's procedures.
• Critical equipment that looks wrong can be taken to local or hand control at the equipment, independent of the BAS. Use the hand-off-auto switches, local controllers or drive keypads the way you would during a controller failure.
• Critical spaces — labs, data rooms, healthcare areas, freezers — need the owner's facilities team told immediately so they can watch conditions directly.

Write down everything you put in hand, and when. You'll need to undo it later, and investigators will want to know which changes were yours.

Isolate at the boundary. Don't wipe.

If you believe someone is actively in the system, the aim is to cut their access without destroying what they've left behind.

Preserve the evidence

While the system is still in the state you found it:

• Photograph the screens with your phone: ransom notes, audit logs, user lists, alarm consoles, active-session windows. A timestamped photo of a screen is a far better record than your memory.
• Export logs if you can do it without changing anything: the supervisor's audit log, alarm history, remote-access logs. Save exports to a clean USB drive or your laptop, not back onto the supervisor.
• Note the current values of anything that looks changed, before you correct it: setpoints, schedules, modes.
• Don't install tools on the supervisor to investigate. Leave that to whoever the owner brings in.

Record times and what you saw

Start a written timeline straight away, on paper or on your phone, not on the supervisor. For each entry: the time, what you saw, what you did, who you spoke to. Include things like "14:05 — AHU-2 discharge setpoint found at 95°F, audit log shows change at 02:13 by user 'maint2', unknown to site staff" and "14:20 — put AHU-2 supply fan in hand at VFD, disconnected BAS uplink at switch in room B12".

Note the supervisor's clock versus real time as well. If it's off, every log entry needs correcting later, and knowing the offset at the time saves a lot of argument. It's one reason time sync is on the hardening checklist.

Call the owner's IT or security contact

Your site documentation should already say who that is. If it doesn't, ask the facility manager for their IT security contact, and add it to your records afterwards. Tell them plainly what you've seen and what you've done so far, and read them your timeline.

From that point, they lead. They may bring in an incident response firm, their insurer or law enforcement. They'll decide what gets reported and to whom. In the US, CISA accepts reports of cyber incidents and publishes guidance for control-system owners; other countries have equivalent national agencies. Reporting is normally the owner's decision, but it's worth knowing the resource exists and mentioning it if the owner seems unsure where to turn.

Also tell your own management. If the compromise came through a contractor account, a service laptop or a remote-access tool your company installed, other customers may be affected, and your company needs to know today.

Don't restore until they agree

Once the building is safe and the system is isolated, there will be pressure to get the BAS back. Hold off until the owner's security contact says it's time. Restoring too early can wipe evidence, and it can also restore the attacker's way back in — the unknown account, the remote tool, the stolen password — if nobody has worked out what it was.

In the meantime, run the building the way you would during a long supervisor outage: controllers on their own sequences, critical equipment in hand where needed, and regular walk-rounds of critical spaces.

Recovery from known-good backups

When recovery is agreed, it usually looks like this:

1. Rebuild the supervisor from a clean operating system install, not by cleaning the existing one, unless the security team says otherwise.
2. Restore the BAS database and controller programs from a backup taken before the earliest suspicious activity. This is where an offline, test-restored backup earns its keep; see "The backup that won't restore".
3. Reset every password: BAS users, controllers, routers, service accounts, the OS, and remote access. Assume all of them are known.
4. Review every account against the owner's list before re-enabling anything. See the accounts nobody owns.
5. Close whatever the investigation found as the way in — a port forward, an unmanaged remote tool, a flat network — before reconnecting.
6. Reconnect in stages, verify every system, and return equipment from hand to auto one piece at a time.

Lessons learned

After the building is back to normal, sit down with the owner and the security team and write up what happened and what changes. The usual findings are depressingly familiar: remote access that was too open (remote access), a network that let the attacker reach the BAS from somewhere else (segmentation), shared or default passwords, no working logs and backups nobody had tested. Each of those has a fix, and the lessons-learned meeting is where the budget for them usually appears.

Finally, add the contacts and the first-hour steps to the site's O&M documentation, so the next person on call doesn't have to work it out at 2 a.m.

Found a wrong number or a broken link? Tell me and I’ll fix it.