Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

How do we…

How do we recover when the attacker may control our sign-in directory?

5 decision pointsThe pack behind this answer: Cyber Resilience & Recovery

Add to board memo

The short answer

Recommendation
Assume the attacker had administrator rights in the directory unless the investigation shows they did not. Rebuild or recover and clean the directory first, in an isolated recovery environment with new administrator accounts, and connect nothing that trusts the old directory until it has been rebuilt in its turn.
Reasoning
Administrator rights in the sign-in directory open every other system, so most destructive attacks reach it. Whoever controls the directory controls every system that trusts it: a system rebuilt cleanly and then joined to a compromised directory is compromised again at once. Stolen credentials also survive a rebuild. Resetting in order closes the attacker's widest access first, and resetting the directory's signing keys twice stops sign-in tokens the attacker forged.
Considerations
  • There are two routes: build a new directory and create accounts again from a reviewed list, or recover a checked copy from before the earliest sign of the attacker and clean it. Both end with the same review.
  • Use sealed emergency accounts only to start the recovery environment or take back a cloud identity tenant. If the attacker could have reached their credentials, treat them as compromised and create new ones.
  • A cloud identity tenant can hold the same foothold. Check its administrators, trusted devices and external trusts the same way.
  • If a managed IT provider runs the directory, agree in advance that it rebuilds with new accounts from clean devices.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartThe attacker may have controlled the sign-in directoryDecisionCan you administer without the accounts the attacker may hold?StepUse sealed emergency accounts only to get startedStepStand up the recovery environment with new admin accountsDecisionHas the investigation shown the attacker had no admin rights there?StepRecover it first with the foundations, as restore or rebuild decidesDecisionIs there a checked directory copy from before the earliest sign?StepRecover that copy in the recovery environmentStepBuild a new directory and create accounts from a reviewed listStepRemove every unknown account, group, policy and trustStepReset credentials in order, and the signing keys twiceStepCheck the cloud tenant's admins, trusted devices and trustsStepRebuild the rest of the foundations, then systems in orderDecisionDoes anything about to connect still trust the old directory?StepKeep it apart until it is rebuilt or rejoined in its turnDecisionDoes the sweep find this attack's indicators or persistence?OutcomeStop reconnecting and hand back to the incident managerOutcomeReturn systems in stages through the gates

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 18 steps.

  1. Start

    The attacker may have controlled the sign-in directory

    Most destructive attacks reach the sign-in directory, because administrator rights there open every other system. Whoever controls the directory controls every system that trusts it: a system rebuilt cleanly and then joined to a compromised directory is compromised again at once. The directory is one of the foundations, and it comes back first.

    In the pack

  2. Decision

    Can you administer without the accounts the attacker may hold?

    If the attacker holds the normal administrator accounts, or the directory they sign in through, the recovery team needs a way in that does not depend on them. Answer yes only if you have a route the attacker could not have reached. If you are not sure, answer no.

    In the pack

  3. Step

    Use sealed emergency accounts only to get started

    Use the break-glass accounts only to start the recovery environment or take back a cloud identity tenant, and no more. Declare and record every use for review. If the attacker could have reached their credentials, treat them as compromised and create new ones. After each use, the session is reviewed and the credential changed and resealed, each within 1 working day by the pack's default.

    In the pack

    See also

  4. Step

    Stand up the recovery environment with new admin accounts

    Build an isolated network with no path to production. Create new administrator accounts there, each held by a named person, with no trust to the production directory: a trust lets any account the attacker holds walk straight in. Work from devices newly built or never connected to the affected network, and run monitoring to a console the attacker could not reach.

    In the pack

  5. Decision

    Has the investigation shown the attacker had no admin rights there?

    Answer yes only when the incident investigation has shown the attacker never held administrator rights in the directory. If it shows they did, or it is not yet known, the directory is rebuilt or recovered and cleaned first. The incident plan's rule is the same: where the attacker had administrator rights, rebuild the systems it controlled, starting with the sign-in directory.

    In the pack

  6. Step

    Recover it first with the foundations, as restore or rebuild decides

    The directory still comes back first among the foundations, restored or rebuilt as the incident manager decides for it. The extra cleaning gate does not apply, but credentials are still reset in the incident plan's order before anything depends on them.

    In the pack

  7. Decision

    Is there a checked directory copy from before the earliest sign?

    The pack allows two routes: build a new directory, or recover one from a copy taken before the earliest sign of the attacker and clean it. A copy is usable only if it predates the earliest sign and passed its integrity check and a scan. If none does, or you cannot tell, build new.

    In the pack

    See also

  8. Step

    Recover that copy in the recovery environment

    Restore the directory from the chosen copy inside the isolated environment, never onto the production network. The copy predates the earliest sign, but something placed before anyone noticed can still be in it, so it is cleaned before anything trusts it.

    In the pack

  9. Step

    Build a new directory and create accounts from a reviewed list

    Install the directory from a trusted build source, an offline image with a matching hash or fresh vendor media, and configure it from a stored, reviewed baseline. Create accounts and groups again from a list someone has reviewed, not by copying them from the affected directory.

    In the pack

  10. Step

    Remove every unknown account, group, policy and trust

    Both routes end with the same review. Remove accounts, groups, policies and trusts nobody can account for, and anything the attacker left behind. Record the review: it is the evidence that the directory was cleaned before any system depends on it.

    In the pack

  11. Step

    Reset credentials in order, and the signing keys twice

    Stolen credentials survive a rebuild. Reset from clean devices, in the incident plan's order: administrator accounts, service accounts, remote access, the backup system, then users, and end all signed-in sessions. Where the directory was compromised, reset its own signing keys twice, so sign-in tokens the attacker forged stop working.

    In the pack

  12. Step

    Check the cloud tenant's admins, trusted devices and trusts

    A cloud identity tenant can hold the same foothold as the on-premises directory. Check its administrators, trusted devices and external trusts the same way, and remove anything nobody can account for.

    In the pack

  13. Step

    Rebuild the rest of the foundations, then systems in order

    After the directory, rebuild the core network and firewalls, the backup platform, and endpoint protection and monitoring, then each system in the recovery order. Patch each before it holds data and close the attacker's way in on every one. Services that depend on the foundations cannot come back sooner than the time it takes to rebuild them.

    In the pack

  14. Decision

    Does anything about to connect still trust the old directory?

    Servers, applications, interfaces and devices joined to the old directory will accept whatever it issues, including what the attacker created. Connect nothing that trusts the old directory until it has been rebuilt in its turn. If you are not sure, answer yes.

    In the pack

  15. Step

    Keep it apart until it is rebuilt or rejoined in its turn

    Leave it disconnected, rebuild it in the recovery order, and join it to the rebuilt directory. Interfaces to suppliers and customers are set up again with new credentials or keys, and the other side confirms. Then ask the question again.

    In the pack

  16. Decision

    Does the sweep find this attack's indicators or persistence?

    Before anything is trusted with users, sweep the directory and each system for this attack's indicators and for ways back in: new accounts, scheduled tasks, remote access tools. Run it before you answer: nothing reconnects on a sweep that has not run.

    In the pack

  17. Outcome

    Stop reconnecting and hand back to the incident manager

    An indicator on a rebuilt system means the attacker may still be in. Stop reconnecting; the system goes back under incident response, and its stage restarts only when eradication is confirmed again.

    In the pack

    See also

  18. Outcome

    Return systems in stages through the gates

    Each system returns only when the clean-room gates and the incident plan's recovery criteria are met and its business owner has tested the service. Reconnect one service or site at a time under closer monitoring, and keep watching through the monitoring period.

    In the pack

    See also

Practical checklist

  1. Stand up an isolated recovery environment with new administrator accounts held by named people, no trust to the production directory, and clean devices.
  2. Rebuild the directory new from trusted build sources and a reviewed baseline, or recover a checked, scanned copy from before the earliest sign.
  3. Remove every account, group, policy and trust nobody can account for, and record the review.
  4. Reset credentials from clean devices in the incident plan's order: administrators, service accounts, remote access, the backup system, then users.
  5. Reset the directory's signing keys twice and end all signed-in sessions.
  6. Check the cloud identity tenant's administrators, trusted devices and external trusts.
  7. Rebuild the rest of the foundations, then systems in the recovery order, keeping anything that trusts the old directory disconnected.
  8. Sweep for this attack's indicators and persistence before each system reconnects in stages.

Evidence to have ready

  • The investigation's finding on whether the attacker held administrator rights in the directory.
  • Every use of an emergency administrator account, its review and the credential change that followed.
  • The route taken for the directory, with the build source hashes or the chosen copy's date and checks.
  • The review of accounts, groups, policies and trusts, and what was removed.
  • The record of credential and signing key resets, in order, with dates.
  • The sweep results and the gate checks for each system before it reconnected.

Assumptions

  • Your incident response has contained the attack, and its investigation can say whether the attacker had administrator rights in the directory.
  • You have emergency administrator accounts sealed and tested under your privileged access standard, or another way in that does not depend on the directory.
  • Where a managed IT provider runs your directory, its contract lets you require a rebuild with new accounts from clean devices.

Not covered here