Containment at the OT Boundary
Atlas Components runs a 24/7 plant with an IT network and a segmented OT network joined by an engineering jump host. Exabeam raises a high-risk sequence: a domain administrator account authenticates to six servers in eight minutes at 02:14, then EDR on one server shows a credential-dumping alert. The jump host has no EDR agent because the vendor will not support it, and it can reach programmable logic controllers used by the production line. The line is currently running a safety-critical batch that cannot be stopped without a controlled shutdown. The account is normally used only by two platform engineers, both offline and unreachable. The SOC has authority to disable accounts and isolate IT hosts but must get plant-manager approval to touch the OT segment. A ransomware note has not appeared, but SMB sessions from the domain admin account are still open.
1. What are the first containment actions, and how do you handle the OT constraint?
Read the worked answer
Treat the domain-admin credential as compromised and act on identity before the OT network. Disable the account, revoke its Kerberos tickets and active sessions, and force re-authentication. If policy allows, reset the password twice for the account and the krbtgt account only after scope is understood, because a golden ticket may exist. Isolate the five EDR-covered servers from the network, but do not power them off; preserve memory. For the jump host, do not unplug or reboot it without plant approval; instead, apply a temporary ACL that blocks IT-to-OT and OT-to-IT traffic except the minimum needed for the running batch, and span its traffic to a capture. Notify the plant manager and OT engineering immediately, explain the safety constraint, and get a joint decision on a controlled shutdown window. Block the domain-admin account at the domain controller and at the VPN. Check for active SMB sessions and kill them. The reasoning is to break the credential's reach without causing a physical safety event; containment of OT is a business and safety decision, not a solo SOC action.
2. What evidence would you preserve, and who should be notified?
Read the worked answer
Preserve volatile evidence first: memory from the EDR-covered server with the credential-dumping alert, the jump host's network capture, and the domain controller's security logs. Export Exabeam session data, authentication logs, SMB session tables, EDR process trees, and the jump host's local logs if accessible. Record the chain of custody and note time sync. Notify the incident commander, IT security, OT engineering, plant management, and legal or privacy per the incident plan; if customer data or safety systems may be affected, notify the executive on-call. Do not notify the two platform engineers through unsecured channels until you know whether their accounts are compromised; contact them by phone through HR. Ask the vendor for jump-host support but do not let them reboot it. Preserve the backup platform logs because initial access may be there. The reasoning is that domain-admin compromise plus OT reach is a potential safety incident, so evidence must support both forensic reconstruction and regulatory or safety reporting.
3. How would you validate eradication before reconnecting the OT segment?
Read the worked answer
Validate eradication before reconnecting in stages. First, prove the domain-admin credential cannot authenticate: check domain controller logs for failed logons, confirm the account is disabled, confirm any krbtgt reset, and scan for scheduled tasks, services, and SID history created by the attacker. Second, rebuild the EDR-covered server from known-good media rather than cleaning in place. Third, for the jump host, if it cannot be rebuilt, compare its file system and services against a baseline, capture a fresh image, and have the vendor attest to integrity; if compromise is confirmed, replace it. Fourth, reconnect the jump host to IT only, with ACLs and monitoring, for 24 hours; then allow OT access during a controlled window with plant engineering watching. Confirm the production line is stable and no unauthorized SMB sessions recur. Re-enable the domain-admin account only with a new password and a break-glass process, or keep it disabled and create a new tiered admin account. Close the incident only after a tabletop review of the OT containment decision.