Detecting T1098 Account manipulation

How T1098 account manipulation keeps an attacker signed in

A valid account that behaves differently after a password reset is one of the clearest signs of T1098 Account manipulation. Under the Persistence tactic (TA0003), ATT&CK describes the adversary as trying to maintain their foothold, and T1098 does this by changing an account that already exists. The adversary adds a credential, a role, a group membership, a key or a permission to that account, so access keeps working after the original compromise is discovered and the first password is changed. Creating a new account is a different behavior, covered by the sibling T1136 page, so a clean account inventory alone does not rule out this technique.

T1098 has seven sub-techniques, and they share one theme: each changes an existing identity in a way that outlives the session. In general terms, they cover extra credentials on cloud identities, delegated mail permissions, additional cloud role assignments, SSH keys trusted by hosts, device registration on an identity provider, additional roles in container cluster administration, and added membership in local or domain groups. This mapping targets Enterprise ATT&CK version 20.0. Confirm the sub-technique names and IDs in the enterprise-attack 20.0 STIX bundle before writing rules, because releases can rename, deprecate or revoke techniques. In intrusions, this behavior usually follows initial access or credential theft, when the adversary wants access that survives a reset.

Start with three decisions. First, choose which identity planes are in scope, such as the identity provider, cloud tenants, mail, container clusters and Linux hosts, because each records changes differently. Second, check whether each source logs the change types described above, including group membership and role assignment events as well as sign-ins. Third, agree which changes may happen without a ticket, so that an unexpected key or role addition stands out. Ask each platform owner which audit events cover these changes and how long they are retained, then test one change in a lab tenant before relying on the alert. The goal is to detect the change before the attacker depends on it.

Which telemetry reveals account manipulation and which open-source tool collects it

This table maps the data components most relevant to T1098 Account manipulation to the signal a defender should look for and the open-source collector that typically gathers it. Read each row as a starting point: the collector named is an example, and platform-specific log sources must be confirmed in your own environment before you rely on them.

Data component	Signal to look for	Open-source collector or source	Confirm in your environment
User Account Modification	Changes to group membership, role assignments, credentials or account attributes on identity systems and hosts	Wazuh agents on Linux and Windows endpoints, forwarded identity audit events to a SIEM	Which directory and identity provider events are logged, and at what detail
Process Creation	Account management commands or utilities launched by unexpected users, parents or sessions	Wazuh agents with process auditing enabled, Security Onion host telemetry	Whether process auditing is enabled on every host class in scope
Command Execution	Shell or management-tool invocations that change privileges, keys or account settings on containers and ESXi hosts	Wazuh agents on Linux hosts, container runtime audit logs forwarded to a SIEM	Whether ESXi and container platforms can forward shell or command history centrally
File Modification	Edits to authorized key files, sudoers configuration, account databases or service account token stores	Wazuh file integrity monitoring on defined paths, Velociraptor hunts on endpoints	Exact paths that hold credentials on each platform, since they vary by distribution and product
Application Log Content	Admin actions in application or platform logs, such as added API keys, new service principals or changed roles	Log shipping from SaaS, IaaS and self-hosted platforms into a SIEM through Wazuh or Security Onion	Which application audit logs exist, their retention and whether the vendor exposes them to your tenant
Network traffic (supporting)	Logins from new sources or service accounts used from unusual hosts, shown in connection metadata	Zeek connection and authentication logs, Suricata alerts, Security Onion dashboards	Whether authentication protocols in use are visible to passive sensors in your network design
Cloud and identity provider audit logs	Role grants, new access keys, MFA method changes and consent to third-party applications	Native audit logs forwarded to a SIEM such as Wazuh or Security Onion	Whether the cloud or identity provider tier includes the audit events you need and how long they are kept

Detection logic for T1098 that SOC teams can tune

The four to six detection ideas below share one principle: T1098 Account manipulation changes an identity that already exists, so the signal is the change itself, not the presence of an account. Each idea needs a baseline of expected change, a short list of approved change sources, and a response path that confirms whether the change was authorized before anyone closes the alert.

Privileged role or group changes

Alert when a user is added to a directory role, an administrative group or a cloud admin policy. The logic is simple: any addition to a privileged group is rare enough to review, so start with every event and tune down only after a few weeks of observed approvals. Thresholds should be set per group, not globally, because a daily change to a help desk group is normal while a change to a domain admin group is not. Common false positives come from provisioning pipelines that grant roles during onboarding and from HR-driven joiner or mover workflows. Check that the actor is the approved pipeline identity and that a matching ticket exists.

Credential or key additions

Alert when a new password credential, certificate, or access key is attached to an existing account, especially a service principal, application registration or a user who has not rotated credentials in a long time. The signal is an addition to an identity that already has access, which is a common way to keep a foothold after a password reset. Tune by separating routine rotation (an old key is removed in the same operation) from pure additions (a second key appears and nothing is removed). Pipelines that rotate secrets and certificate renewal jobs are the main false positive sources, so match on the expected automation identity and key naming convention.

Permission changes on service accounts

Alert when a service account gains new permissions, a broader scope, or a new delegation, such as an added API permission or a role binding at a higher scope. Service accounts rarely change, so a change that widens access is a strong indicator of manipulation. Tune by keeping a baseline of expected permission sets per account and alerting on any difference, not on every modification. Infrastructure-as-code deployments are the usual false positive, since they update role bindings on purpose. Confirm that the change came from the approved repository pipeline and that the commit or change request matches the modification.

Changes outside change windows

Alert when account changes occur outside approved maintenance or business windows, or when changes are made by an identity that normally works only during one shift. Time alone is weak, so combine it with the other signals: an admin role grant at 2 a.m. from an unusual source is far more meaningful than a routine password reset at the same hour. Set the window per environment and agree it with the operations team before tuning. Emergency changes and follow-the-sun support teams create false positives, so require an incident or change record reference for every out-of-window change that is accepted.

Account changes that follow no ticket

Alert when an account modification has no matching change request, onboarding record or HR event within a set time after it occurs. This correlation idea catches manipulation that uses a legitimate-looking channel, because the attacker's change lacks the paper trail that a normal change produces. Build the join between the identity provider or directory logs and the service desk or HR system, then review unmatched events daily at first. The main false positives are delays in ticket entry and changes made by vendors through their own portals, so agree a grace period and an approved vendor list with the business owners.

How to validate that the T1098 detection fires

This sequence proves that the T1098 detection fires on a benign account change in a test tenant, measures how quickly the signal reaches the analyst, and keeps the analytic stable as ATT&CK releases change the technique. It produces a validation record that a CISO or compliance lead can review.

Agree scope and approval in writing
The detection owner, the platform owner for the identity provider and the test tenant administrator agree in writing which accounts, groups, roles and log sources are in scope. The approval names the test tenant, the change window and the rollback owner, and confirms that no production identity is touched. Done when the signed scope record is filed with the detection ticket and the SOC lead has acknowledged it.
Confirm the target ATT&CK version and mapping
Record the ATT&CK version the detection targets, for example v20 or the version the team has pinned, and the sub-techniques of T1098 it is meant to cover, such as account-level group or role changes on identity providers and cloud IAM. Check the linked detection strategy and data components against the STIX bundle for that version. Done when the mapping sheet lists each analytic, its data component and the version it was validated against.
Prepare a benign change to a test account
A test tenant administrator makes a small, reversible and documented change to a dedicated test account, such as adding it to a non-privileged group and removing it again. The change is performed through the normal administrative interface or API by a named operator, so that the audit record reflects a legitimate actor. Done when the operator's change plan lists the exact object, the time of the change and the reversal step.
Record the expected log events beforehand
Before the change, the detection engineer writes down the events that should appear: the identity provider audit event for the membership or role change, the actor and target fields, and the forwarding path into the SIEM, such as Wazuh or a comparable pipeline. Compare these against the data component requirements of the analytic. Done when the expected-event table is reviewed, so that a missing field is found before the test rather than during it.
Execute the change and capture timestamps
The operator makes the change and reverses it, while a second person records the source event time, the time the event lands in the log store, the time the rule evaluates and the time the alert appears in the queue. Pipeline latency is the difference between these points. Done when the timeline shows each stage with a timestamp and the alert identifier is linked to the test ticket.
Assess alert fidelity and fields
The analyst reviews the generated alert and checks whether it names the actor, target account, action and tenant, and whether the benign test is classified correctly. Record the outcome as a true positive for the test event, and note any false positive or missing field. Done when the fidelity record shows the fields present, the enrichment applied and the analyst's disposition.
Tune and run regression tests on each ATT&CK release
Adjust thresholds, allow lists and field mappings only through change control, then re-run the same benign scenario and a set of prior test cases. Repeat the validation whenever MITRE releases a new ATT&CK version, since releases can rename, deprecate or revoke techniques and change detection mappings. Done when the regression results for the pinned version pass and the change log records the version, the reason and the approver.
Store the validation evidence for review
Save the scope record, mapping sheet, event table, timeline, fidelity review and regression results together in the detection repository, and link them to the rule version. The evidence supports internal governance and gives independent assessors a traceable record, although it is not an audit or certification on its own. Done when the record is complete and the detection owner signs off on the validation.

Why the ATT&CK version and sub-technique scope matter for your rules

Every detection you write for T1098 Account manipulation should name the ATT&CK version it targets, because the framework changed its structure recently and the change affects how rules are mapped. With ATT&CK v18, released October 28, 2025, MITRE replaced the detections in technique pages with detection strategies and analytics, made major updates to data components, and deprecated data sources. v19 followed on April 28, 2026, and v20 on October 13, 2026. A rule that cites a technique ID without a version can look correct in a coverage report while pointing at data components or analytic logic that no longer match the current release. Record the version in the rule metadata, the coverage spreadsheet and the detection-as-code repository so that an auditor or a new engineer can see which mapping was intended.

T1098 has sub-techniques that span very different platforms, including containers, ESXi, IaaS and identity providers, so a single technique-level mapping hides gaps. Keep a register that lists each platform rule against the specific sub-techniques it covers, the data components it depends on (for example, User Account Modification or Cloud Service Modification, depending on the platform), and the log source that feeds it. Then confirm that register against the enterprise-attack STIX bundle for the version you target, which MITRE publishes in the attack-stix-data repository. The attack-stix-data repository is the natural starting point for pulling the bundle. Treat any sub-technique missing from the register as uncovered until a rule and a test say otherwise. Confirm the current sub-technique count for T1098 in that bundle rather than relying on figures from earlier releases.

Preventive controls that shrink the T1098 attack surface

T1098 succeeds when an adversary can change an account that already has useful rights, so the most effective preventive work limits who holds those rights and which features can change them. The cards below cover the two primary ATT&CK mitigations and two supporting controls that give you the logs and the account hygiene needed to notice what slips through.

Privileged account management

Privileged Account Management (M1026) is the primary control against T1098 because account manipulation is most damaging when it touches administrative roles, service principals or directory admin groups. Inventory every account and role that can add credentials, change group membership or grant permissions, and confirm each one has a named owner and a documented reason. Review which of these privileged identities are used interactively and move them to separate administrative accounts with stronger authentication. Expect the review to surface standing privilege that nobody currently needs.

Disable or remove unused features

Disable or Remove Feature or Program (M1042) reduces the number of places an account can be changed. Many T1098 sub-techniques depend on features such as cloud role assignment APIs, container orchestration RBAC bindings, or ESXi local user management, and each enabled feature is another path to alter an account. Confirm which of these features your environment actually uses, disable the rest through configuration, and record the decision so the change is reviewable. Verify the disabled state after every platform upgrade, since defaults can return.

Audit account changes

Audit (M1047) is a supporting control: it does not stop a change, but it makes one visible. Confirm that audit logging is enabled for credential changes, group membership changes and role assignments on each platform in scope, and that logs are forwarded to a store the account administrators cannot quietly edit. Test one controlled change per platform and confirm the event arrives with the actor, the target and the time. Gaps found here usually decide whether the later detection work can succeed.

User account management hygiene

User Account Management (M1018) covers the lifecycle controls that keep accounts from accumulating unexplained changes: provisioning through an approved workflow, prompt deprovisioning, and periodic recertification of access. Check that dormant accounts and orphaned service accounts are identified and disabled, and that an account change without a matching ticket or onboarding record is treated as a finding. These controls are cheap to describe and easy to skip, so ask for evidence of recertification cycles rather than accepting a policy statement.

Triage steps when an account manipulation alert fires

The first decision in an account manipulation alert is whether the change was authorized, and it should be made by checking the change record rather than by the analyst's instinct. Compare the alerting event against approved tickets, change windows and the identity owner's confirmation for the specific account. Check who performed the change, from which host or session, and whether that actor normally administers this identity provider, container registry, ESXi host or cloud tenant. Keep the question narrow: did a named person intend this specific permission, group membership, key or role change? If no approved record exists within the expected window, treat the alert as a suspected incident and open a case with a single owner. Document the answer and the evidence that supports it before moving on.

Once the change is judged unauthorized or unexplained, scope it before touching anything. Identify every other identity, group, role, API key, token or resource the affected account has created, granted or accessed since the modification, because persistence rarely stops at the first changed object. Pull the audit trail for the account's actions over that window and for the actor who made the change, and list the platforms involved, such as Entra ID, Okta, Kubernetes, vSphere or the cloud control plane. Contain in the order the identity owner agrees to: disable or restrict the account, revoke active sessions and tokens, then rotate credentials and secrets the account could read. Coordinate each step with the platform owner so that rotations do not break production workloads, and record the time of every action.

Preserve evidence before cleanup changes the record. Export the relevant audit logs, identity provider sign-in and admin events, and platform configuration snapshots to write-protected storage, and confirm that retention on the source systems will not expire during the investigation. Keep a decision log that records who was told what, who approved each containment step, and why any step was deferred. Confirm with your identity and platform owners, and with legal or compliance where required, how long the evidence must be retained. Afterward, feed the outcome into your detection tuning, so that confirmed-benign changes become documented baselines and confirmed malicious changes become test cases for the cyber range exercises described on this page.

Rehearsing T1098 detection in a private cyber range

Build the lab with a dedicated identity provider tenant or directory instance that mirrors your production configuration for administrative roles, group membership, credential registration and application consent. Forward the provider's audit and sign-in logs into the same pipeline your SOC uses, so the rehearsal tests the real path from event to alert. Benign injects should include routine changes such as adding a user to a privileged group through the approved change workflow, registering a new authentication method for a test account, and granting an application a permission during a sanctioned onboarding. Good detection means each change produces a normalized event that identifies the acting identity, the target object and the change type within the expected time, and that a rule scoring privileged group changes outside an approved change window raises an alert. Good response means the analyst can confirm the change against the ticket, revert it, and record the decision. Confirm with your provider which audit event categories and retention periods it exposes, because these vary by license tier.

Log path: Verify that audit events reach the SIEM with the actor, target and timestamp fields intact.
Approved change injects: Run group and role changes that have matching tickets so you can measure false positives.
Out-of-window injects: Make privileged changes without a ticket and confirm the alert fires and routes correctly.
Revert drill: Practice removing an unauthorized role assignment and confirming it is gone in the provider console and logs.
Evidence capture: Export the relevant audit records and attach them to the case with the approval status.

Check that your alert thresholds were tested against your own change volume, not a generic baseline.

Questions SOC leads and detection engineers ask about T1098

How do you tell a legitimate admin change from account manipulation?

Start from the change record, not the event. A permission grant, group membership change or new credential on an account is only suspicious when no approved ticket, maintenance window or known administrator explains it, or when the actor, source host or time falls outside normal patterns. Build an allowlist of routine administrative actions per platform, such as service accounts that rotate keys on a schedule, and alert on deviations from that baseline. Enrich every hit with who performed the action, from where, and whether the same actor touched other privileged objects in the same session. Treat a privileged role being added to an account that was recently created or recently used from an unfamiliar network as a higher priority than a routine group change. Validate the baseline with the identity team before tuning rules, because an overly broad allowlist hides the very activity T1098 describes.

Which logs should we retain for T1098 detection, and for how long?

Retain the sources that record account changes on each platform in scope: identity provider audit logs, directory service change events, cloud control plane activity logs, container orchestration audit logs, and hypervisor management logs. Record the data components most often referenced for this family, such as User Account Modification and Process Creation, so each log maps to a detection you can test. Retention length is a legal and regulatory decision, not a technical one. Confirm the period with your counsel, your compliance lead and any sector regulator, and document the basis in your retention schedule. Also confirm that logs are forwarded off the source system before local rotation, that timestamps are synchronized, and that integrity controls are in place so that an attacker with administrator rights cannot silently alter the audit trail.

What do we do with T1098 sub-techniques that have no native telemetry?

Be explicit about the gap rather than writing a rule that cannot fire. For each sub-technique, check the current ATT&CK analytics and data component guidance for the platform, then mark whether your environment produces the required telemetry. Where it does not, you have three practical options: enable native auditing if the platform supports it, forward a related source such as Application Log Content or cloud control plane events that partially covers the behavior, or record the gap as accepted risk with a compensating control such as periodic configuration review. Document each decision in your coverage register with the owner and review date. Confirm with the platform vendor which audit settings exist in your version, because capabilities differ across releases and deployments.

How can we test T1098 rules without affecting production?

Replay recorded or simulated account changes against a copy of the detection pipeline before enabling any alert. Use a private cyber range or an isolated lab tenant that mirrors your identity provider, directory, container platform and hypervisor configuration as closely as your data allows. Run only approved, scripted administrative actions in that environment, log each action with a timestamp, and check whether the expected alert fires within your target window. Measure false positives against a week or more of normal administrative activity, and record the results with the rule version. Roll rules out in a monitor-only mode first, then promote them once the owner accepts the noise level. Confirm change-freeze and notification requirements with operations before any test that touches shared infrastructure.

How do ATT&CK version changes affect our T1098 mappings?

Each ATT&CK release can rename, deprecate or revoke techniques and sub-techniques, and it can change the detection strategies and data components they reference. Pin every detection mapping to the ATT&CK version it targets, and record that version in your rule metadata. When a new version is published, compare the affected technique and sub-technique IDs against your register, review the release notes for changes to T1098 and its data components, and update the mapping before retiring the old one. ATT&CK v18 replaced technique-level detections with detection strategies and analytics, and v19 and v20 followed, so older rules written against legacy detection text need a documented translation. Schedule the review as part of your detection lifecycle, and confirm the version your SIEM content pack or vendor library uses.

How do we measure detection coverage for T1098 in a way auditors accept?

Measure coverage per platform and per sub-technique, not as a single percentage. For each of the seven sub-techniques, record whether a rule exists, whether its required data source is ingested and healthy, whether it has been validated in a cyber range exercise, and when it was last tested. Use a simple status scale such as validated, deployed untested, telemetry missing, or not applicable with reason. Link each rule to the mitigations you rely on, including Privileged Account Management and Disable or Remove Feature or Program, and show evidence that those controls operate. Review the register after every ATT&CK release and after major platform changes. Ask your assessors early which evidence format they expect, since coverage claims need evidence behind them and DeployOpen prepares that evidence without issuing an assessment opinion.

Primary sources for T1098 and the Persistence tactic

Start with the MITRE ATT&CK tactic page for Persistence (TA0003) before writing any detection for T1098 Account manipulation. The page defines the tactic as the adversary trying to maintain its foothold, which is the frame your detection should answer to: an altered account is only persistence if it survives a password reset, a session expiry or a removed initial access path. Read the technique and its sub-technique pages from that tactic page, and confirm which of T1098's sub-techniques are active in the version you target, since the tactic lists the technique alongside other Persistence techniques that share some of the same data components.

Next, read the ATT&CK updates index and the release notes for the version you map to. Detection mappings change between releases. Since v18, detections on technique pages are expressed as detection strategies and analytics, and data components have been revised and some data sources deprecated. Before you rely on a mapping, confirm with the release notes whether T1098 or any of its sub-techniques were renamed, deprecated or revoked, and record the ATT&CK version in your detection repository so later reviewers can reproduce your coverage claims.

For machine-readable mapping, use the enterprise-attack 20.0 STIX bundle. It lists the relationships between T1098, its sub-techniques, the data components and the mitigations, including Privileged Account Management and Audit, so you can generate a coverage matrix instead of maintaining one by hand. Validate the bundle against the version your SIEM rules declare, and treat a mismatch between the bundle and the release notes as a question to resolve with MITRE before you publish coverage.

How DeployOpen builds T1098 detections and range exercises

DeployOpen approaches T1098 Account manipulation as a self-hosted engineering task inside the client's own cloud accounts, data centers or air-gapped networks. The work starts with a written scope that names the platforms, telemetry and ATT&CK version in play, then moves through detection content, validation and cyber range rehearsal.

How we scope

Engagements are fixed-scope, with platforms, log sources and the T1098 sub-techniques in play agreed in writing before work starts.
We confirm which identity providers, container platforms, ESXi hosts and IaaS accounts produce account change telemetry in your environment.
We record the ATT&CK version the detection mapping targets, since releases can rename, deprecate or revoke techniques.

How we build

We build detection logic for user account modification and process creation events tied to privileged account changes on the scoped platforms.
We configure open-source collection and analytics, such as Wazuh or Security Onion, to ingest those events with consistent field mapping.
We align Sigma-format rules and the ATT&CK Privileged Account Management and Audit mitigations with the controls already in your estate.

How we hand over

You receive detection documentation describing each rule's logic, data sources, known gaps and the environment it was tested against.
Validation results from controlled test activity are delivered with the rules, so your team can rerun them after changes.
A cyber range runbook covers how to rehearse detection and response for T1098 Account manipulation without touching production.

How we support

Ongoing support, rule tuning and upgrades for new ATT&CK releases are available as a retainer, scoped separately.
Continuous testing of account manipulation detections can be added to a retainer, with the frequency agreed in writing.
Compliance readiness material can be prepared as evidence for your assessors, which independent auditors then evaluate. Confirm the scope with your assessor first.

T1098 Account manipulation