# Account Manipulation (MITRE ATT&CK T1098)
Account manipulation is the attacker's answer to a simple problem: new accounts are detectable, but modifications to existing accounts are not. Creating a new privileged user account in an environment with mature identity monitoring will generate alerts. Adding a secondary credential, an additional role assignment, or a forwarding rule to an account that already exists is operationally quieter, provides access that survives password resets, and often evades detection controls focused on account creation rather than account modification.
MITRE ATT&CK classifies account manipulation as T1098, a technique primarily serving the persistence tactic but also enabling privilege escalation depending on the account targeted and the modification made. The technique is not new. Adding backdoor credentials to compromised accounts has been standard attacker practice since the early days of Unix intrusions, when adding entries to /etc/passwd or ~/.ssh/authorized_keys was a reliable way to survive discovery and remediation.
What has changed is the surface area. Modern enterprise environments span on-premises Active Directory, multiple cloud tenants (Azure, AWS, GCP), dozens of SaaS platforms, and hybrid identity systems connecting all of them. Each platform has its own credential model, its own role assignment mechanism, and its own audit log format. An attacker who understands these surfaces can add credentials and permissions in cloud environments that an organization is monitoring with an on-premises-centric security operations model and never trigger an alert.
Account manipulation is at the intersection of two PDM domains: TID (Threat Intelligence and Defense), which detects and characterizes the technique as an adversary behavior pattern, and IAT (Identity Access and Trust), which owns the identity controls, access reviews, and continuous verification mechanisms that prevent and detect it. The CDA methodology that directly addresses this technique is Zero Possession Architecture (ZPA): "Trust nothing. Possess nothing. Verify everything." In a ZPA-governed identity environment, every account modification is a detection event, not a configuration change.
Cloud identity platforms are built around the concept of multiple credential types attached to a single identity. AWS IAM users can have console passwords, access keys (up to two), and MFA devices. Azure service principals and app registrations can have multiple certificate credentials and client secrets. GCP service accounts can have multiple key pairs. This multi-credential design serves legitimate purposes (credential rotation without downtime), but it creates a persistence surface: add a credential, and access persists even if the original credential is rotated or disabled.
The attack pattern for T1098.001 follows initial access into a cloud environment with sufficient permissions: enumerate existing identities, identify high-privilege targets (IAM users with administrator access, service principals with broad permissions, workload identities with cross-account roles), and add a new credential. The new credential may be an AWS access key pair, an Azure application secret or certificate, an SSH key on a cloud-hosted instance, or an OAuth token granted to an attacker-controlled application.
AWS access key addition is particularly common in cloud breaches because access keys provide programmatic API access from anywhere on the internet, do not require MFA by default, and are not subject to conditional access policies that might block console login from unexpected locations. An attacker who adds a secondary access key to an existing IAM user can use that key indefinitely, even after the compromised user's console password is reset, as long as no one specifically disables the additional key.
The Azure equivalent: adding a client secret or certificate to an existing app registration or service principal. In the Microsoft breach reported in 2024 (attributed to APT29, also known as Midnight Blizzard), the attackers obtained access to a legacy OAuth application that had been granted broad Microsoft 365 permissions and used that application's credentials to access mailboxes across the organization. The technique combined T1098.001 (additional credentials on the OAuth application) with T1098.002 (email delegation access).
Email delegation is a legitimate enterprise feature: an assistant needs access to an executive's mailbox, or a shared mailbox needs to be accessible to a team. The technical mechanism in Microsoft Exchange (on-premises and Exchange Online) is the FullAccess, SendAs, and SendOnBehalf permission grants attached to a mailbox.
Attackers with access to Exchange administrative permissions, or with access to a mailbox owner's credentials, add delegation permissions to attacker-controlled accounts. The consequence is persistent read and send access to the victim's mailbox that survives the victim's password being changed. Password resets are the most common remediation action taken during an account compromise response. If delegation has been granted, the reset of the primary credential does not revoke delegation, and the attacker retains full access.
Business Email Compromise (BEC) operations routinely use T1098.002 as their persistence mechanism. After accessing the victim's email account (typically through credential phishing), the attacker adds delegation access for a free email account they control, then conducts financial fraud operations from that persistent access over days or weeks. By the time the fraud is detected, the delegation has been in place long enough to have been overlooked in the initial response.
The send-as capability is equally significant: an attacker with SendAs access can send email that appears to originate from the victim's address in every client and email header, enabling internal spearphishing campaigns that exploit the established trust of the victim's identity within the organization.
Cloud role assignment is the mechanism by which access is granted in cloud platforms. In Azure, roles (Owner, Contributor, Global Administrator, specific service roles) are assigned to users, groups, or service principals scoped to subscriptions, resource groups, or individual resources. In AWS, IAM policies are attached to users, groups, or roles. In GCP, IAM bindings assign roles to principals on resources.
T1098.003 is the addition of privileged role assignments to attacker-controlled accounts or to compromised accounts the attacker is leveraging. The objective is either persistence (ensure the attacker retains access even if a specific credential is revoked) or privilege escalation (add a more powerful role to an account that initially had limited permissions).
The stealth advantage of role manipulation over account creation: adding a role assignment to an existing account is a lower-signal event than creating a new privileged account. In environments where role assignments are reviewed periodically rather than monitored continuously, role additions made between review cycles may persist for months before discovery.
The Midnight Blizzard (APT29) Microsoft breach also demonstrated T1098.003: after obtaining access through the legacy OAuth application, the attackers added the application to privileged roles within the Microsoft 365 tenant that granted access to additional mailboxes and services beyond the initial compromise scope.
On Linux and Unix systems, SSH public key authentication is the standard mechanism for remote administrative access. The ~/.ssh/authorized_keys file for each user contains the list of public keys authorized to authenticate as that user. Any process running as the user (or as root) can modify this file.
The persistence technique is straightforward: append the attacker's public SSH key to the authorized_keys file of a privileged user or a service account with significant system access. From that point forward, the attacker can authenticate as that user over SSH from any host where they hold the corresponding private key, regardless of whether the account's password is known or changed.
T1098.004 is a primary persistence technique in Linux server environments, cloud virtual machine intrusions, and container host compromises. It is also used in lateral movement scenarios: once inside a network, adding SSH keys to multiple hosts' authorized_keys files creates a web of persistent access that is difficult to fully remediate without auditing every host's authorized_keys files individually.
Detection is straightforward in principle but frequently missed in practice: file integrity monitoring (FIM) on ~/.ssh/authorized_keys files will alert on any modification. Centralized SSH key management (ensuring that authorized_keys is generated from a managed key repository rather than maintained manually) eliminates the local-file modification vector entirely.
Modern identity platforms, primarily Microsoft Azure Active Directory (now Entra ID) and similar enterprise identity providers, support device-based authentication through Device Compliance and device-bound credentials. When a device is registered in Azure AD, it obtains a device certificate and can acquire a Primary Refresh Token (PRT) that allows single sign-on to Azure AD-integrated services without re-authenticating.
T1098.005 is the attacker registering a new device under the victim's identity in the identity platform. Once the device is registered, the attacker can use that device to obtain a PRT and maintain persistent authenticated access to all services integrated with Azure AD, including Exchange Online, SharePoint, Teams, and any third-party SaaS applications using Azure AD as their identity provider. This access persists even after the victim's password is reset, because the device certificate is independent of the password credential.
The technique requires either access to the victim's credentials or access to an administrator account with the ability to register devices on behalf of users. In environments where device registration is not restricted (all users can register devices, no device compliance checks are enforced before registration grants PRT access), a compromised user account provides everything needed to establish persistent device-bound access.
Incident response teams consistently face a specific remediation failure mode: an organization detects a compromise, resets the affected user's password, and considers the incident contained. Two weeks later, the attacker is back. The password reset addressed the initial access credential but did not address secondary credentials, delegated permissions, role assignments, or registered devices that the attacker had established during the dwell period.
Effective account manipulation remediation requires enumerating and revoking every modification the attacker made to the identity layer, not just the initial access credential. This is operationally difficult because the modifications may span multiple systems (Exchange, Azure AD, AWS IAM, on-premises Active Directory, third-party SaaS) and may have been made days or weeks before detection.
CrowdStrike's adversary dwell time data, now measured in days for e-crime actors and weeks for nation-state actors, reflects how much time attackers have to establish account manipulation persistence before detection. Every day of undetected access is another opportunity to add credentials and permissions that will survive the initial remediation.
Many identity monitoring strategies focus heavily on detecting new account creation. This is necessary but insufficient. T1098's fundamental insight is that modifying existing accounts provides better operational security for attackers: the modified account has an established history, established relationships with other users and systems, and is less likely to be flagged as anomalous than a brand-new account. Alerting on new high-privilege account creation while not alerting on privilege role additions to existing accounts is a common detection gap.
Business Email Compromise losses exceeded $2.9 billion in 2023 according to the FBI's Internet Crime Report. The majority of these losses trace directly to T1098.002 (email delegation) and related persistence techniques. The email delegation persistence model allows attackers to observe financial workflows over extended periods, identify the right moment to redirect a payment, and conduct the fraud from an email address that recipients recognize as legitimate. Organizations that cannot detect delegation permission changes are exposing themselves to an attack that costs an average of $125,000 per incident in direct losses, plus investigation and remediation costs.
| Sub-Technique | Platform | Primary Log Source | Key Event / Signal | |---------------|----------|-------------------|-------------------| | T1098.001 | AWS | CloudTrail | CreateAccessKey, PutUserPolicy | | T1098.001 | Azure | Azure AD Audit Logs | Add credentials to application | | T1098.002 | Exchange Online | Unified Audit Log | Add-MailboxPermission, Add-RecipientPermission | | T1098.003 | Azure | Azure AD Audit Logs | Add member to role | | T1098.003 | AWS | CloudTrail | AttachRolePolicy, PutGroupPolicy | | T1098.004 | Linux | File integrity monitoring | ~/.ssh/authorized_keys modification | | T1098.005 | Azure | Azure AD Audit Logs | Register device, Add device |
All of these events are available as audit log entries. The detection gap in most organizations is not the absence of log data but the absence of alerting logic that fires on these specific events. A SIEM rule that fires on any Add credentials to application event in Azure AD, with enrichment to determine whether the application receiving credentials has privileged permissions, provides near-real-time detection of T1098.001 in the Azure context.
AWS CloudTrail logs every IAM API call, including CreateAccessKey, which fires whenever a new access key is created for an IAM user. An effective detection rule fires on CreateAccessKey events where the user for whom the key is created is not the caller (an administrator creating a key for another user, or an attacker with sufficient IAM permissions creating a key for a targeted high-privilege user). Combining this with an alert on the number of active access keys per user (flagging any user with two active keys who did not recently perform a key rotation) provides both detection and hygiene monitoring.
Exchange Online delegation changes are logged in the Microsoft 365 Unified Audit Log under the Add-MailboxPermission and Add-RecipientPermission operations. Effective monitoring includes alerting on any delegation grant where the grantee account is not a known service account and was not associated with an IT helpdesk request. Given the volume of BEC attacks that depend on this technique, organizations should consider reviewing existing mailbox delegation configurations as part of an identity audit, not just monitoring for new grants.
Azure AD / Entra ID provides controls to restrict device registration:
Environments that have not enforced these controls are fully exposed to T1098.005. Reviewing the device inventory in Entra ID and identifying devices registered outside the corporate provisioning process is an effective baseline assessment.
Zero Possession Architecture (ZPA) addresses account manipulation directly through its core principle: "Trust nothing. Possess nothing. Verify everything." In a ZPA-governed identity environment, standing credentials are minimized and access is continuously verified rather than statically granted.
The practical application to T1098: ZPA controls require that account modifications (credential additions, role assignments, delegation grants) are treated as access requests requiring the same verification as initial access. A service account that adds a new API key should require the same approval workflow as a new user requesting privileged access. An application that is granted additional permissions should require re-certification before the grant takes effect.
CDA's IAT missions map directly to T1098 detection: IAT-R01 (identity exposure reconnaissance) includes enumeration of cloud credentials, role assignments, and delegation configurations that exist outside the documented and approved access model. Anything not in the approved model is a potential T1098 artifact, either attacker-placed or an ungoverned administrative action that presents equivalent risk. IAT-B01 (identity hardening) includes remediation of ungoverned credentials and access, not just the initial access credential.
Most organizations running workloads across AWS, Azure, and GCP have identity security monitoring tools that are strong on one platform and weak on the others. AWS CloudTrail and Azure AD Audit Logs use completely different schemas, different event names, and different enrichment requirements. T1098 variants are platform-specific: the AWS version involves IAM access keys, the Azure version involves app registration credentials and device objects, the Linux version involves authorized_keys files.
CDA's TID detection engineering work maintains cross-platform detection coverage for T1098, normalizing events from CloudTrail, Azure AD Audit Logs, GCP Audit Logs, and Linux audit frameworks into a unified alert model. This is not a trivial implementation: it requires platform-specific collection, normalization, and Sigma/SIEM rule development for each sub-technique on each platform. Organizations that are monitoring one cloud platform's identity logs but not others have blind spots that sophisticated attackers exploit by conducting their account manipulation activity specifically in the least-monitored cloud environment.
MITRE Corporation. "Account Manipulation (T1098)." MITRE ATT&CK, 2024. https://attack.mitre.org/techniques/T1098/
Microsoft Security Response Center. "Midnight Blizzard: Guidance for responders on nation-state attack." Microsoft, January 2024. https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/
FBI Internet Crime Complaint Center. "2023 Internet Crime Report." FBI IC3, 2024. https://www.ic3.gov/Media/PDF/AnnualReport/2023_IC3Report.pdf
CISA. "Identifying and Mitigating Living Off the Land Techniques." CISA Advisory, 2024. https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-038a
CrowdStrike. "2024 Global Threat Report." CrowdStrike, 2024. https://www.crowdstrike.com/global-threat-report/
Mandiant. "APT29 and the SolarWinds Compromise." Google Cloud Threat Intelligence, 2024. https://cloud.google.com/blog/topics/threat-intelligence/apt29-solarwinds
Microsoft. "Entra ID Identity Protection: Device Registration." Microsoft Learn, 2024. https://learn.microsoft.com/en-us/entra/identity/devices/
AWS. "Logging IAM and AWS STS API calls with AWS CloudTrail." AWS Documentation, 2024. https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html
CDA, LLC. "Zero Possession Architecture (ZPA) Methodology Reference." CDA Canon, 2026.
CDA, LLC. "Predictive Defense Intelligence (PDI) Methodology Reference." CDA Canon, 2026.