No Known-Good Administrative Workstation for Recovery

During response and rebuild, administrators keep using their regular workstations or devices whose integrity has not been established to change passwords, access consoles, and deploy new systems.

No clean administrative workstation has been prepared, and no procedure exists to establish one quickly. The team ends up rebuilding trust from a tool that may already belong to the attacker.

A compromised workstation can capture new secrets, tokens, and procedures as they are created. It can let the attacker observe the response, follow communications, learn which systems have been restored, and immediately reclaim the new access.

Password rotation and rebuilding then become theater: the keys change, but someone is watching over their shoulder as they’re handed out.

The problem also extends to external vendors. A responder who connects from an unvalidated machine can reintroduce risk into a freshly rebuilt environment.

• Ask which device the most sensitive operations would be performed from if every regular administrative workstation were suspect.
• Check whether a dedicated workstation exists, along with a protected reference image, the necessary hardware, and an attestation procedure.
• Review the rules restricting access to critical consoles to approved devices only.
• Test how long it actually takes to produce a clean device without relying on the compromised infrastructure.
• Include vendor devices and personal workstations in the assessment; “it’s new” or “it belongs to the consultant” is not proof of integrity.

• Maintain a small number of dedicated, hardened administrative workstations reserved for privileged operations.
• Keep a reference image, along with the necessary tools, drivers, keys, and procedures, in a protected location.
• Enforce conditional or network-based access so that critical consoles reject unapproved devices.
• Separate routine activity from administrative activity, and prohibit email, general browsing, and unnecessary tools on these workstations.
• Periodically test building or restoring a clean workstation.
• Define requirements for external responders before an incident occurs.

• Stop performing critical rotations and changes from suspect devices.
• Build a clean workstation from trusted media and image, on a controlled network, using only the necessary tools.
• Establish a clean administrative identity first; then use that device-identity pair for the remaining rotations.
• Restrict the workstation’s connectivity to required destinations only, and log its activity.
• If no device can be attested, document this risk and use the most isolated stopgap solution available; do not present the resulting access as “trusted.”