MITRE ATT&CK T1098 Account Manipulation Guide: Detecting Persistence Through Identity Changes

Once an attacker holds one valid identity, the cheapest way to keep it is to quietly change it: add a key, a role, a group, a device or a delegate that survives a password reset. MITRE ATT&CK tracks this as T1098 Account Manipulation, a technique that sits in both the Persistence (TA0003) and Privilege Escalation (TA0004) tactics and spans Windows, Linux, macOS, ESXi, network devices, containers, IaaS, SaaS, Office suites and identity providers. This guide covers all seven ATT&CK v20 sub-techniques, their mapped detections and log sources, and the mitigations that make these changes hard to make and easy to see. It is written for detection engineers, identity and cloud administrators and incident responders.

Key takeaways

• T1098 is about change, not login. The signal is a modification to an identity (credential, role, group, delegate, key or device), so your audit pipeline for identity changes matters more than your sign-in analytics.
• Non-human identities are a favourite target. Adding a secret or certificate to an existing service principal, or a new access key to a cloud user, gives durable access that user-focused controls such as MFA and session revocation do not touch.
• Seven sub-techniques, one pattern. T1098.001 to T1098.007 cover cloud credentials, email delegation, cloud roles, SSH authorised keys, device registration, Kubernetes role bindings and local or domain groups; each has a specific audit event you can alert on.
• Prevention is privilege design. MITRE's mitigations come down to removing the right to make these changes from ordinary accounts (M1018, M1026), forcing MFA and approval on the ones that remain (M1032), and switching off unused mechanisms (M1042).
• Response must sweep for persistence. Resetting a password does not remove an added key, role or delegate; every identity incident needs an explicit check of all seven change types.

How the attack works

ATT&CK defines account manipulation as any action that preserves or modifies adversary access to a compromised account, such as modifying credentials or permission groups. It always follows an earlier foothold, typically MITRE ATT&CK T1078 Valid Accounts, and is often paired with MITRE ATT&CK T1136 Create Account. The defender's mental model has three parts:

• Precondition: the attacker controls an identity that already has some right to modify identities, roles, files or policies. Over-privileged helpdesk, automation and service accounts are the usual enablers.
• The change: a write to an identity store (directory, IdP, cloud IAM, Kubernetes RBAC, mailbox permissions, an authorised keys file or an MFA device list).
• The payoff: access that outlives the original foothold, or a higher privilege level than the stolen identity had.

The v20 technique page (version 2.8) lists the following sub-techniques. All are in the Persistence and Privilege Escalation tactics.

Where it shows up

• Cloud and identity provider tenants: new client secrets or certificates on Entra ID applications and service principals, new IAM access keys or console login profiles in AWS, new service account keys in Google Cloud, and new global or privileged role assignments. See the Azure RBAC and Service Principals Guide and the Google Cloud IAM and Service Accounts Guide.
• Email and collaboration: mailbox permissions and folder permissions in Exchange Online and on-premises Exchange, and delegation in Google Workspace.
• Linux, macOS, ESXi and network devices: keys in ~/.ssh/authorized_keys, in ESXi's per-user key files, or bound to privileged accounts on routers and switches. See the SSH Key Management Guide.
• MFA and device management: a new authenticator or device registered after a credential compromise, which then satisfies MFA or device-based Conditional Access. See the MFA Fatigue and Bypass Guide.
• Kubernetes: bindings that attach powerful roles to an attacker-controlled user or service account. See the Kubernetes RBAC Guide.
• Active Directory and local hosts: additions to Domain Admins, Administrators, Remote Desktop Users or Linux groups such as sudo or wheel, plus account attribute changes such as SID History or delegation settings.

Impact

• Persistence that survives standard remediation: password resets and session revocation do not remove an added application secret, access key, SSH key, delegate or registered device.
• Privilege escalation: role, group and binding changes turn a low-value foothold into tenant, domain or cluster administration.
• Control bypass: registered devices satisfy MFA and device compliance checks; application credentials authenticate without any user sign-in.
• Data access at scale: application permissions and mailbox delegation can expose many mailboxes or datasets at once. In the Microsoft Midnight Blizzard breach, a legacy test OAuth application was used to create further malicious OAuth applications and grant the Exchange Online full_access_as_app role, giving mailbox access without any executive's credentials.

Detection

ATT&CK v20 attaches a detection strategy to the parent technique and to each sub-technique. The table lists the strategy, the log sources MITRE names, and the specific events to alert on. Treat a change by an identity that does not normally administer identities, from an unusual network, or shortly after a risky sign-in as high severity.

Practical points that make these detections work:

• Turn the logs on first: Windows events 4738 and 4728 to 4757 need the Audit User Account Management and Audit Security Group Management subcategories enabled through Advanced Audit Policy. Kubernetes audit logging must be configured with a policy that records RBAC objects at Metadata level or higher. Microsoft 365 unified audit and CloudTrail management events must be retained centrally.
• Watch the attributes Microsoft calls out: for 4738, Microsoft recommends monitoring critical accounts by target name, and flagging SID History that is not empty, changes to AllowedToDelegateTo, and User Account Control flags such as Don't Require Preauth, Password Not Required and Don't Expire Password.
• Correlate, do not just count: a credential added by a deployment pipeline is routine; the same change by a user who just signed in from a new country is not. Join change events with the preceding sign-in and process context.
• Baseline the change agents: allowlist the automation identities that legitimately make each change by identity, source and change type, so a compromised automation account still alerts.

Metrics that show it is working:

• Percentage of the seven change types with a live, tested alert (target 100 per cent for cloud credentials, cloud roles and privileged groups).
• Median time from a privileged identity change to analyst triage.
• Number of standing identities able to add credentials or assign roles, tracked down over time.
• Count of application and service principal credentials older than policy, or without a named owner.

An identity threat detection and response capability is the natural home for these analytics. See the ITDR Guide.

Prevention and hardening

MITRE maps seven mitigations to T1098. The table turns each into concrete controls.

Platform-specific guardrails worth adopting:

• Google Cloud: enforce iam.managed.disableServiceAccountKeyCreation and iam.managed.disableServiceAccountKeyUpload. Google states that the legacy versions of these constraints are enforced by default for organisations created on or after 3 May 2024; older organisations should check.
• Entra ID: restrict who can register applications and consent to permissions, require approval for privileged role activation, and use application credential policies to limit secret lifetimes. See the Entra ID Applications and Consent Guide.
• Kubernetes: follow MITRE's advice to avoid wildcard permissions and the system:masters group, and prefer RoleBindings over ClusterRoleBindings. Restrict the bind and escalate verbs to cluster administrators, and use admission control to reject bindings to cluster-admin outside a break-glass path.

Rollout order

1. Inventory change rights: list every human and non-human identity that can add credentials, assign roles, change groups, register devices or edit mailbox permissions.
2. Enable and centralise logs: confirm each event in the detection table actually reaches the SIEM; test by making a benign change in a lab tenant.
3. Deploy alerts in report-only mode: run for two to four weeks, tune the allowlist of legitimate change agents, then move to paging.
4. Remove standing rights: convert privileged role and group membership to just-in-time with approval, starting with tenant and domain administrators.
5. Apply guardrails: organisation policies, Conditional Access for registration, admission control. Pilot on one subscription, project or cluster, keep a documented exception process, and roll back by switching the policy to audit if a business process breaks.
6. Rehearse the sweep: run a tabletop where responders must find and revert one example of each sub-technique.

Small and large organisations

A small organisation with one cloud tenant should start with its IdP and cloud provider's built-in alerts for role assignment and credential addition, plus the guardrails above. Large organisations need the full detection table in a SIEM or ITDR platform, an owner for every application credential, and reconciliation of role and group membership against an approved state.

Lessons from incidents

• Legacy applications are persistence waiting to happen: the Microsoft Midnight Blizzard breach shows how an old test OAuth application with elevated access became a platform for new applications and a high-privilege app role assignment. Alerting on "Add app role assignment to service principal" and new application creation would have surfaced the change.
• Password resets alone leave the door open: responders who reset the compromised user but do not review application credentials, role assignments and registered devices leave every T1098 change in place.
• Ownerless non-human identities: credentials added to a service principal nobody owns go unnoticed for months. See the OWASP NHI Top 10 NHI1 Improper Offboarding Guide.

Framework mapping

Practitioner checklist

• Map each of T1098.001 to T1098.007 to the platforms you run and name the log source for each.
• Enable Audit User Account Management and Audit Security Group Management, Microsoft 365 unified audit, CloudTrail management events and Kubernetes RBAC auditing.
• Alert on credentials added to service principals, applications and cloud users, and on any privileged role or group assignment.
• Alert on new MFA methods and device registrations, especially within hours of a risky sign-in.
• Remove the right to add credentials or assign roles from general-purpose and automation identities that do not need it.
• Put privileged roles behind just-in-time activation with approval and phishing-resistant MFA.
• Enforce key-creation restrictions for cloud service accounts and disable app passwords and unused delegation.
• Add a seven-point persistence sweep to every identity incident playbook.

Standards and references

• MITRE ATT&CK: Account Manipulation (T1098)
• MITRE ATT&CK: Additional Cloud Credentials (T1098.001)
• MITRE ATT&CK: Additional Cloud Roles (T1098.003)
• Microsoft Learn: 4738(S) A user account was changed
• Microsoft Learn: Microsoft Entra audit log activity reference
• Google Cloud: Restricting service account usage
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: ITDR Guide · MITRE ATT&CK T1552 Unsecured Credentials Guide · Git Secret Scanning Guide · OWASP NHI Top 10 NHI2 Secret Leakage Guide · MITRE ATT&CK Guide for Defenders