Movement, sessions, and lasting access

Two questions help organize an identity incident: where could the activity go next, and what would let it continue later? They are connected, but answering one does not answer the other.

Lateral movement concerns an adversary reaching other systems or resources from an initial foothold. Remote sign-ins are one possible mechanism. Network routing and reachability merely establish a route; the destination still has its own authentication, authorization, and service behavior.

A sign-in is evidence with context

Windows security events can describe the type of logon, the account, the authentication package, and other context. A network logon and an interactive desktop logon are different events to interpret. Neither label alone identifies malicious intent.

Imagine a fictional support account connecting to a server at night. Check the approved maintenance window, source device, destination, rights, and subsequent activity. A successful logon proves less than “the account administered the server,” and far less than “every server was compromised.”

Correlate records carefully. Clocks, missing logs, shared accounts, and retention gaps can limit a timeline. State which event came from which system.

A session is not the same as a password

A session can remain authenticated after the initial exchange. Kerberos tickets have lifetimes and protocol rules; web applications may maintain their own sessions or refresh credentials. These are separate mechanisms.

Resetting a password does not universally terminate every existing ticket or application session. Closing a laptop also does not prove that every copy of a credential is gone. During recovery, the responsible administrators need to establish which forms of access exist and how each is invalidated.

Avoid a blanket instruction to rotate every directory key. Recovery of critical identity infrastructure requires a coordinated plan, dependency knowledge, and verification.

What makes access persistent?

Persistence describes maintaining access across interruptions or changes that would otherwise remove it. Some mechanisms survive a reboot; others survive a session ending, a password change, or another event. Name the actual lifetime instead of assuming all persistence is permanent.

Examples to review defensively include unexpected account creation, changed group membership, altered access rules, new credentials, and unapproved service or scheduled-work configuration. These are indicators to investigate, not proof of wrongdoing by themselves: legitimate administration changes the same objects.

Review two kinds of residue

Active residue includes sessions and credentials that may still be accepted. Stored residue includes permissions and configuration that can create access again later. Removing one category does not automatically remove the other.

In our fictional incident, a password reset may address a known secret while an unexplained group membership remains. The team should confirm whether that membership was approved, whether it grants relevant access, and which systems may have consumed it. Preserve enough evidence to understand the change before deciding how to restore the intended state.

Define what recovery means

A good recovery record names the affected identity, the change or credential under review, the owner, and the verification result. “Password reset completed” is an action. “Known sessions ended, unauthorized membership removed, and access checks now match policy” is a more complete outcome when the evidence supports it.

Pair containment with service continuity. Isolating a critical server or disabling a shared service identity can interrupt legitimate work. Assign decisions to accountable owners, preserve necessary evidence, and verify the final state rather than assuming a single action closed the incident.