Account Manipulation

Existing identities can become durable access

Account manipulation changes an existing identity or its associated settings to preserve or expand access. An actor may alter permissions, add credentials, change recovery-related details, or otherwise modify the account's relationship with services. The exact opportunities depend on the identity platform and the authority already obtained.

This behavior differs from creating a completely new account. An established identity may already have trusted relationships, familiar naming, and access to important resources, making an unauthorized change less conspicuous than a new user appearing in the directory.

Examine a quiet permission change

At a fictional academy, a staff account unexpectedly gains a privileged group membership. The audit record identifies the target account, the modifying principal, the time, and the requested change. The investigator checks the result and compares it with approved access requests.

The modifying principal may be a provisioning service rather than the person who requested the change. Trace the workflow where evidence allows: request, approval, service action, and resulting access. A legitimate automation identity can still be abused or misconfigured.

The team reviews other changes to the same account during the relevant period. A password reset, added authenticator, new application credential, or delegated permission can have different effects on continued access. Do not assume that reviewing group membership alone covers every persistence path.

Separate expected administration from abuse

Job changes, temporary projects, and recovery workflows legitimately modify accounts. Check the business purpose, approving owner, intended duration, and actual permission scope. A change ticket is useful context but should correspond to the observed identity and operation.

Conversely, a familiar account name is not evidence that a change is safe. Attackers can operate through genuine identities, and an unauthorized credential added to a known account may survive the first password change.

Least privilege and Secure account recovery explain why permissions and recovery paths need distinct review. The incident scope should follow the access granted, including resources reached after the modification.

Restore the intended account state

Preserve the before-and-after configuration and audit trail where available. Remove unauthorized changes through an approved process, review active access routes, and address the identity that performed the modification. Confirm that required business access still functions after remediation.

For practice, compare an approved temporary group assignment with an unexplained new credential on the same fictional account. Identify which owner should approve each, which records establish the change, and how expiration or revocation would be verified. Incident reporting and handover should distinguish the change itself from any later activity performed using the resulting access.

Related concepts

• MITRE ATT&CK
• Logs and telemetry
• Incident response
• Valid Accounts