Account Manipulation (T1098)

What is account manipulation?

Account manipulation is when an attacker who already has access to an account changes it to keep that access. MITRE ATT&CK tracks it as T1098, across seven surfaces from cloud credentials to registered MFA devices. Because the change outlives the credential, resetting the password alone does not remove the attacker.

If you have found something on an account and already reset the password, the useful question is the next one: did that finish it? The answer depends on what else was added while the attacker was inside, and a credential change reaches exactly one of the things on that list.

Two corrections before the detail, because both are commonly got wrong. First, this is not one tactic but two: ATT&CK maps account manipulation to Persistence and Privilege Escalation. Second, it presupposes access. In MITRE's own words, "the adversary must already have sufficient permissions on systems or the domain" before they can manipulate an account at all.

That makes it a technique that happens after the intrusion, not one that starts it. What follows is where the boundary sits, the seven surfaces, the audit event each one leaves, and what a reset does and does not remove.

Explain It Like I'm 10

Think of someone who talks their way into an office building for one afternoon. Before they leave, they do three quiet things: they cut a spare key, they add their name to the cleaning rota so the door gets opened for them, and they sign out a visitor badge in their own name. Then they walk out. That evening, the building changes the lock on the front door. That undoes exactly one of the three.

Account manipulation, valid accounts, credential theft: where the boundary sits

Four terms get used for overlapping situations, and on a page whose readers map findings to technique IDs, the difference has to be exact.

One trap here catches almost every write-up on the subject.

The example everyone reaches for is Scattered Spider registering their own MFA tokens. That behaviour is account-manipulation-shaped, but the joint CISA and FBI advisory that documents it does not map it to T1098. It maps the MFA-token registration to T1556.006 and T1606, and the group's federated-identity-provider abuse to T1484.002. The string T1098 does not appear in that advisory at all. The advisory also notes that the federation tactic "has not been identified as a current TTP", so it should not be presented as live behaviour.

The practical consequence is small and sharp: if a report cites T1098 for that campaign, a reviewer can correct it. Attribute each identifier to the document that actually makes it.

The seven surfaces

ATT&CK has not treated account manipulation as one behaviour since 2017. It is split into seven sub-techniques, and which of them are even reachable depends on what an environment runs.

The fourth column is the whole argument, and it is the same answer seven times because the additions are not the credential.

Three of them deserve naming precisely:

• Additional cloud credentials (T1098.001): an adversary adds credentials for service principals and applications in addition to the existing legitimate ones. An application that suddenly authenticates from somewhere new is a persistence finding, not a misconfiguration.
• SSH authorized keys (T1098.004): the `authorized_keys` file on Linux, macOS and ESXi hosts, where a single added line survives every password change anyone makes.
• Additional local or domain groups (T1098.007): this reaches further than Domain Admins. MITRE names VPN user groups and, on Linux, the sudoers group, and notes that machine accounts can be added to domain groups too.

What none of this looks like is malware. It is a second key in a file, a delegate on a mailbox, an extra group membership. Housekeeping, performed by someone who should not be doing it. That also makes it a poor thing to chase by indicator: an added credential is trivially replaced, while the behaviour of adding one is not, which is the distinction the pyramid of pain exists to make.

Device registration, and why it connects to everything else

T1098.005 is the surface that has changed most. An adversary who compromises a user's credentials may enroll a new device to bypass the initial MFA requirement and gain persistent access. MITRE notes that in some cases the self-enrollment process "may require only a username and password to enroll the account's first device or to enroll a device to an inactive account", which makes dormant accounts a real exposure rather than a theoretical one.

Once registered in Entra ID or Intune, a device can be used to reach resources while bypassing conditional access policies. It can also send internal spearphishing over intra-organizational email, which the receiving client is less likely to treat as suspicious.

This is the point where account manipulation and MFA fatigue meet. Prompt-bombing is about getting one approval out of a user; registering your own authenticator is about never having to ask for one again.

How do you detect account manipulation?

The signal for this technique lives in identity and system audit logs, not on the endpoint. The sign-in log, the directory audit log, `auditd`, the macOS unified log and the SaaS admin log are where these changes are recorded, and an EDR agent will not carry most of them.

MITRE publishes a named detection strategy for the technique, DET0096, with six analytics split by platform. Here they are in the framework's own terms.

• Windows (AN0265): account attribute changes such as password set, group membership, `servicePrincipalName` and logon hours, correlated with unusual process lineage or timing. Log sources are `WinEventLog:Security` event codes 4738, 4728 and 4670, plus Sysmon event 1. The event codes are already on vendor pages; the correlation condition is what turns them from noise into a detection.
• Identity provider (AN0268): modifications to SSO and SAML user attributes such as `isAdmin`, role, MFA bypass and app assignments, made through CLI, API or rogue IdP apps. In Okta these surface as User Attribute Modified and Role Assignment Changed events. For most readers this is the row that matters.
• Linux (AN0266): use of `usermod`, `passwd` or `groupmod` to escalate or persist, correlated with login or process events, via `auditd` syscall and path records on `/etc/passwd` and `/etc/group`.
• macOS (AN0267): account changes through `dscl`, `pwpolicy` or `sysadminctl` that alter groups, enable root or bypass MDM, in the unified log.
• ESXi (AN0269): new users or role changes such as ReadOnly to Admin, particularly from non-jumpbox addresses.
• SaaS (AN0270): role escalation such as Editor to Owner in cloud collaboration tools, in the Microsoft 365 unified admin log.

One honest qualifier belongs here rather than at the end: a published analytic is only a detection where the log is actually collected and retained. Several of these events sit in logs that many organizations enable but never route to a SIEM.

Does a password reset remove the attacker?

It addresses the credential. It does not touch what was added alongside it.

Walk it against the surfaces above and the pattern is the same every time. An added service principal credential still authenticates. An `authorized_keys` entry still accepts its key. A mailbox delegate still reads the mailbox. A group membership still grants what the group grants. A registered device is still a registered device. None of those is the password, so changing the password does not reach them.

Revocation is the stronger move, and it is still not instantaneous. Entra access tokens last one hour by default, and Microsoft states that "there could be a period between the initiation of access revocation and when access is effectively revoked."

The sharpest limit is one the identity provider documents about itself:

"To revoke a session token, the application must revoke access based on its own authorization policies. Microsoft Entra ID can't directly revoke a session token issued by an application."

Which means eviction is a sequence rather than a switch. Microsoft lists disabling the account, revoking refresh tokens, and disabling the user's registered devices as three separate actions - and that separation is why the device step is the one teams skip. An account can be disabled, its tokens revoked, and an attacker-registered device left in place.

This is also why the clock on an intrusion runs longer than most teams expect, and why the access preserved here is what a later stage of an attack eventually spends.

Where this argument stops

Three bounds, because the case above is easy to over-read.

• The password reset is prescribed, not pointless. Microsoft's own sequence disables the account and then resets the password twice, "to mitigate the risk of pass-the-hash, especially if there are delays in on-premises password replication." Necessary but not sufficient is the honest reading; useless is not.
• The token lag is a default, not a law. Continuous Access Evaluation revokes session and access tokens for applications that support it, and Microsoft says it is working to bring near-real-time invalidation to more of them. The hour is a configuration gap, not a ceiling.
• The analytics have a precondition. Six published detections are worth what the environment's log collection makes them worth. The argument here is that the signal exists, not that account manipulation is reliably caught.

Two limits on the sourcing itself, stated rather than hidden. CISA's Eviction Strategies Tool carries a dedicated entry for this technique, but its countermeasure list does not render in the page as served, so this article does not characterize what it recommends. And no percentage appears anywhere above for how often attackers register rogue devices or add credentials, because no measured figure was found that would survive scrutiny.

What the controls genuinely do is narrow who can reach these surfaces. Phishing-resistant MFA, conditional access and regular privileged-role review all reduce the population of accounts an attacker can manipulate. None of them enumerates what was already added, which remains a hunting job.

Common questions about account manipulation

Which tactic is account manipulation? Both Persistence and Privilege Escalation. It is one of the techniques ATT&CK maps to two tactics, because the same action that preserves access can also widen it - adding a role or a group membership does both at once.

Does it require admin rights already? In substance, yes: MITRE states the adversary must already have sufficient permissions on the system or domain. That makes it a post-access technique. Finding it means something earlier already succeeded, and that belongs in the incident note.

Which actors are documented using T1098? MITRE's own procedure examples name Sandworm Team, Calisto, HAFNIUM, Lazarus Group, and Mimikatz's Skeleton Key functionality. Those are the T1098-mapped cases. Scattered Spider is the one to avoid citing here, for the reason given above.

Is T1098.005 the same as an MFA fatigue attack? No, and the difference is useful. Fatigue is about extracting one approval from a user under pressure. Device registration is about enrolling an authenticator the attacker controls, so no approval is ever needed again.

What to go check

The additions outlive the credential, so the check is an enumeration rather than a reset.

Five places, in your own environment:

1. Credentials added to service principals and applications.
2. Mailbox delegates and forwarding rules.
3. `authorized_keys` entries on Linux, macOS and ESXi hosts.
4. Group memberships, including VPN groups and sudoers.
5. Registered devices and authenticators, especially on dormant accounts.

Then the second half, which is the one the documentation actually points at: find out whether your own eviction runbook reaches tokens and registered devices, or stops at the password. Most runbooks were written for a lost laptop, not for someone who spent an afternoon adding themselves to things.

Reset the credential, then go count what else has a way in.