Remote access tools get found and removed. A quiet extra account often does not. T1136, Create Account, is the persistence technique where an adversary with enough access creates an account for later use. MITRE says such an account provides secondary credentialed access without needing a persistent remote access tool on the system.
The tactic is persistence. The platforms are many: Windows, IaaS, Linux, macOS, Network Devices, Containers, SaaS, Office Suite, Identity Provider and ESXi.
How attackers use it
Accounts can be created on the local system, within a domain or in a cloud tenant. Each has its own sub-technique:
- Local Account (T1136.001). For example
net user /addon Windows,useraddon Linux, ordscl -createon macOS. - Domain Account (T1136.002). For example
net user /add /domain, on a domain controller. - Cloud Account (T1136.003). Users, and service accounts such as Azure service principals and managed identities, created through an identity provider or cloud API.
MITRE adds a note about cloud environments: adversaries may create accounts that only have access to specific services, which can reduce the chance of detection. A small account with narrow access draws less attention than a new global admin.
The MITRE page lists groups that have used the technique, including Scattered Spider.
How to detect it
The detection strategy covers each platform:
- Windows. Built-in tools such as
net user, PowerShell or MMC snap-ins create local or domain accounts. Look at Event ID 4720 (a user account was created) together with process lineage and user context. - Linux.
useradd,adduseror similar commands or scripts. Look at command execution and the audit trail of changes to thepasswdandshadowfiles. - macOS.
dsclcommands, GUI tools, or edits to user plist files. Watchdsclinvocations and plist changes. - Identity providers. New users made through an IAM or identity provider API or portal, such as Azure AD or Okta. Monitor API calls and admin action logs, and correlate with role assignments.
- Cloud services. Account creation through cloud APIs or the CLI, often together with key generation, seen in CloudTrail or the equivalent audit logs.
The common thread is context. A new account is normal when HR or an onboarding process asks for it. It is a finding when it comes from a server at 3 a.m., from a process that has nothing to do with provisioning, or from an actor that does not normally create accounts.
How to reduce the risk
MITRE lists four mitigations.
- Multi-factor authentication for user and privileged accounts.
- Privileged account management. Limit the number of accounts permitted to create other accounts, and do not let domain administrator accounts do day to day work that could expose them on unprivileged systems.
- Network segmentation. Limit access to domain controllers and the systems used to create and manage accounts.
- Operating system configuration. Protect domain controllers by securing critical servers.
Check your own environment
Windows, local accounts and administrators (read-only):
Get-LocalUser | Select-Object Name, Enabled, LastLogon
Get-LocalGroupMember -Group Administrators
Linux, accounts with UID 0 and recent account creation messages:
awk -F: '$3 == 0 {print $1}' /etc/passwd
grep -E 'useradd|new user' /var/log/auth.log
On Red Hat family systems the log is /var/log/secure instead of auth.log.
macOS:
dscl . -list /Users UniqueID
AWS, list IAM users with creation dates, then find who made them:
aws iam list-users --query 'Users[].[UserName,CreateDate]' --output table
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=CreateUser
For each unexpected name, find the ticket or the person who asked for it. No owner, no account.
Quick check
Which Windows event ID records a new user account?
Event ID 4720, a user account was created.
Why do attackers create cloud accounts with narrow access?
MITRE notes that accounts limited to specific services can reduce the chance of detection.
Sources
- MITRE ATT&CK, T1136 Create Account
