Detecting and Mitigating Account Manipulation (T1098)

Getting into an account is one problem for an intruder. Staying in it after the password is reset is another. Account Manipulation (T1098) covers the changes attackers make to keep or raise their access. MITRE files it under persistence and privilege escalation, and lists a very wide set of platforms: Containers, ESXi, IaaS, Identity Provider, Linux, macOS, Network Devices, Office Suite, SaaS and Windows.

There are four sub-techniques, covering additional cloud credentials, additional email delegate permissions, additional cloud roles and SSH authorized keys. They have their own guides. This one covers the parent.

How attackers use it

MITRE says adversaries may manipulate accounts to maintain or elevate access to victim systems. Account manipulation is any action that preserves or modifies an adversary's access to a compromised account, such as changing credentials or permission groups. It can also be activity meant to subvert security policy. MITRE's example is performing iterative password updates to bypass password duration policies and keep compromised credentials alive.

Two conditions apply. To create or manipulate accounts, the adversary must already have enough permission on the system or the domain. And the manipulation may lead to privilege escalation where the changes grant additional roles, permissions or access to higher privileged valid accounts.

That first condition is useful for defenders. It means this technique is usually a second step, which gives you a chance to catch an intrusion at the moment it tries to dig in.

How to detect it

MITRE's strategy (DET0096) is a behavior chain: an account change correlated with unusual process lineage or timing. By platform:

• Windows: attribute changes such as password set, group membership, servicePrincipalName or logon hours, correlated with unusual process lineage or timing.
• Linux: native tools or scripting such as usermod, passwd and groupmod used to escalate permissions or persist on existing users, correlated with login or process events.
• macOS: changes through dscl, pwpolicy or sysadminctl that alter user groups, enable root or bypass MDM restrictions.
• Identity providers: changes to SSO or SAML user attributes, such as isAdmin, role, MFA bypass or app assignments, often through CLI, API or rogue IdP apps.
• ESXi: new users or role permission changes, for example from ReadOnly to Admin, through the API or vSphere Client, particularly from IP addresses that are not jump boxes.
• Collaboration suites: role escalation, such as Editor to Owner, in Google Workspace, Office 365 or file sharing apps.

The lasting value of this list is the pairing. An admin changing a group is normal. The same change from an odd process, an odd source or an odd hour is not. Make sure account and group change events, from directories, identity providers and cloud audit logs, go to a log store where you can join them to the actor.

How to reduce the risk

MITRE lists these mitigations:

1. Use multi-factor authentication for user and privileged accounts.
2. Do not allow domain administrator accounts to be used for day to day operations that expose them on unprivileged systems (Privileged Account Management).
3. Make sure low privileged accounts cannot modify accounts or account related policies (User Account Management).
4. Protect domain controllers with proper security configuration, limiting unneeded protocols and services such as SMB file sharing (Operating System Configuration).
5. Limit access to critical systems and domain controllers with access controls and firewalls. Most cloud environments support separate VPC instances for more segmentation (Network Segmentation).
6. Restrict access to sensitive files that deal with authentication and authorization (Restrict File and Directory Permissions).
7. Remove unnecessary and potentially abusable authentication and authorization mechanisms where possible (Disable or Remove Feature or Program).

Check your own environment

• Who can change group membership, roles and credentials in each system? Is that list short?
• Are account change events alerted on, with the actor named?
• Do privileged accounts ever log in to ordinary workstations?
• Do any low privileged accounts hold rights to edit accounts or IAM policy?

On Linux, a read-only look at recent account changes recorded by the auth log (the file name varies by distribution, and some use the journal instead):

grep -E 'usermod|useradd|groupmod|passwd' /var/log/auth.log | tail -20

On Windows, Security event ID 4738 records a changed user account and 4728 or 4732 record additions to security groups. You can list recent ones with:

wevtutil qe Security /q:"*[System[(EventID=4738)]]" /c:10 /rd:true /f:text

Quick check

Sources

• MITRE ATT&CK, T1098 Account Manipulation: https://attack.mitre.org/techniques/T1098/