Domain Admin Credential on a Shared OT Jump Host
A manufacturing plant runs SAP MES and a DMZ. During a penetration test, testers find a domain admin service account, svc_OTbackup, logged into a shared jump host OT-JUMP-01. The host has RDP access to 14 HMIs and a historian. The password is four years old and is stored in a scheduled task on a server that was decommissioned but still powered on in a closet. The account is in Domain Admins because a vendor needed to install backup agents in 2021. The OT network is flat; the jump host is dual-homed. The plant runs 24/6, with a 6-hour maintenance window on Sunday. The domain functional level is 2012 R2, and an upgrade is planned in nine months. The CISO asks for a 30-day remediation plan without disrupting production. The backup team says the account is required for nightly backups of the historian.
1. What do you contain within 48 hours, and what do you deliberately not do yet?
Read the worked answer
Findings, ranked: domain admin exposure, dual-homed jump host, stale task on a forgotten server, flat OT network, and shared local admin.
Within 48 hours:
- Reset svc_OTbackup password twice and remove it from Domain Admins.
- Restrict the account to logon as a batch/service only on the historian and backup server; deny interactive and RDP logon.
- Disable the scheduled task on the decommissioned server and power it off after imaging.
- Enable LAPS or a unique local admin password on OT-JUMP-01.
- Add firewall rules so OT-JUMP-01 can reach only the 14 HMIs and historian on required ports.
- Monitor for 4624/4672 events and new Domain Admin group changes.
Deliberately not yet: do not re-architect the flat network or change the domain functional level in 48 hours. Do not delete the account until the backup dependency is replaced; removing it without a replacement causes a production outage and undermines the security team's credibility. That is a Sunday-window change, not a 48-hour panic change.
2. Lay out a 30-day remediation plan that respects the 24/6 production schedule and Sunday windows.
Read the worked answer
Week 1 - credentials and exposure: remove Domain Admin, implement logon restrictions, rotate the password, disable the stale server, and add jump-host firewall rules. Validate nightly backup still runs in the Sunday window.
Week 2 - split the backup dependency: create a dedicated OT backup service account with least privilege on the historian only. If the backup application supports a group managed service account, use it; if not, use a restricted service account with a host allowlist. Test restore, not just backup.
Week 3 - jump host hardening: remove dual-homing by placing OT-JUMP-01 behind an RDP gateway or a monitored conduit. Require MFA for vendor and administrative access. Deploy a privileged access workstation for OT admin tasks.
Week 4 - segmentation pilot: segment two HMIs and the historian into a pilot OT zone with a firewall conduit. Document exceptions for the remaining 12 HMIs with dates.
Every change gets a rollback step and a Sunday window. A 30-day plan that ignores the maintenance window is not a plan; it is a request for an outage.
3. How do you handle the 2012 R2 domain functional level and the vendor's application constraints without accepting indefinite risk?
Read the worked answer
Do not let the nine-month domain upgrade become the reason to leave Domain Admin on an OT service account.
Now: use compensating controls that do not require a forest upgrade - remove the account from Domain Admins, restrict logon to specific hosts, use firewall rules and a jump host, and monitor privileged group membership. If the domain supports authentication policy silos, use them; if 2012 R2 does not, document that limitation and use host restrictions instead.
Vendor constraint: if the backup application cannot run under a least-privilege account, treat that as a vendor risk, not an operations fact. Get a written support statement, set an expiry date, and record a time-bound risk acceptance with the plant manager as risk owner. Require the vendor to provide a supported path before the domain upgrade.
Nine-month plan: include OT service accounts in the domain upgrade design; do not migrate them as Domain Admins by default. Track the exception in the risk register with a review at 90 days and a hard expiry. Indefinite acceptance is not acceptable; a dated exception with evidence is.