The first thing an intruder does with a new shell or a stolen key is ask "who am I, and who else is here?" MITRE ATT&CK tracks the host version of that question as T1033 System Owner/User Discovery, a Discovery (TA0007) technique on Linux, macOS, Network Devices and Windows: identifying the primary user, the logged-in user, the set of users who commonly use a system, or whether a user is active. The same reflex appears in the cloud, where a stolen access key is usually tested with an identity self-check before anything else. This guide covers how adversaries use the technique, the detections that separate attacker self-checks from everyday administration, the cloud identity equivalent for machine credentials, and how to test your coverage. It is written for detection engineers, SOC analysts and teams who own service accounts and cloud keys.
Key takeaways
- whoami is a context signal, not a verdict. Admins run it constantly; a web server worker, database engine, Office process or service account running it is a strong indicator of compromise.
- Session discovery chooses the next move. Commands such as
query userandquser, or reading logon events, tell an attacker who is logged in and whose credentials might be in memory. - Cloud self-checks are the stolen-key tell. AWS states that
sts:GetCallerIdentityneeds no permissions and still works under an explicit deny, which makes it the safest first call for anyone holding an unknown key. You cannot block it, so detect it. - Machine identities make the best baselines. A service account or workload key has a fixed set of callers, networks and user agents; an identity check from anywhere else is high fidelity.
- There is no preventive mitigation in ATT&CK. ATT&CK states the technique cannot be easily mitigated with preventive controls, so the work is telemetry, baselines and response.
What the technique covers
ATT&CK v20 (technique version 1.6, no sub-techniques) notes that user details are everywhere on a system: process ownership, file ownership, session information and logs. It names whoami; w and who on Linux and macOS; dscl . list /Users on macOS; environment variables such as %USERNAME% and $USER; and on network devices show users and show ssh through T1059.008 Network Device CLI. It also notes that user details can be gathered through OS credential dumping, and that the results shape whether the adversary fully infects the target.
Enumerating domain accounts and group membership is a separate technique; see the T1087 and T1069 Account and Permission Group Discovery Defensive Guide. T1033 is narrower: who owns this system and who is using it now.
How adversaries use it
| Goal | ATT&CK v20 procedure examples | Why it matters to the defender |
|---|---|---|
| Confirm the current identity and its privileges | Wizard Spider used whoami to identify the local user and their privileges; APT41 executed whoami, including remotely through WMIEXEC | Runs seconds after exploitation or initial execution; the parent process is the giveaway |
| Find active sessions worth targeting | FIN8 ran quser; Dragonfly used query user; Medusa Group used PsExec to run quser remotely | Precedes credential theft from memory and lateral movement to hosts where admins are logged in |
| Map users to hosts from logs | Volt Typhoon ran PowerShell Get-EventLog security -instanceid 4624 to identify user and computer account names (joint NSA and partner advisory, May 2023, cited by ATT&CK) | Reading the Security log in bulk is unusual outside SIEM forwarders and should alert |
| Agent-driven discovery | In the AI-assisted breach of Mexican government infrastructure (C0064), the adversary used Claude Code to discover user details through whoami | Agents run self-checks automatically; the burst pattern is the same, only faster |
The cloud equivalent: identity self-checks with stolen keys
ATT&CK v20 does not list IaaS as a T1033 platform, so this section is an NHI Mgmt Group mapping rather than an ATT&CK one. The behaviour is the same: a person holding an unknown credential first asks the provider who it belongs to. Cloud enumeration of resources after that step is T1580 Cloud Infrastructure Discovery.
Providers are listed alphabetically.
| Provider | Self-check | What the documentation states | Where to detect it |
|---|---|---|---|
| AWS | aws sts get-caller-identity (API GetCallerIdentity) | No permissions are required, and the call still succeeds if a policy explicitly denies sts:GetCallerIdentity. It returns the account ID, the ARN and the unique ID of the caller. | CloudTrail, which logs all authenticated STS API requests. Calls to the global endpoint are logged in US East (N. Virginia) with endpointType and awsServingRegion fields; regional endpoint calls are logged in their own Region. |
| Google Cloud | gcloud auth list | Lists accounts whose credentials have been obtained through gcloud init, gcloud auth login or gcloud auth activate-service-account, and shows the active account. | Host process telemetry on the machine where it runs; service account key activation on an unfamiliar host is the stronger signal. |
| Microsoft Azure | az account show | Gets the details of a subscription, by default the default subscription. | Host process telemetry; on the server side, Microsoft Entra sign-in logs include service principal and managed identity sign-ins. |
Because the AWS call cannot be denied, a single GetCallerIdentity from an access key with no other activity is a classic sign of key validation: someone found or bought the key and is checking whether it works. The EmeraldWhale 2024 operation shows the pattern at scale: the toolset checked tokens recovered from exposed Git configuration files against the GitHub API to confirm they were live, before cloning repositories and testing harvested AWS keys. For the investigation steps that follow such an alert, see How to Investigate CloudTrail for a Compromised Access Key.
What to detect and where
ATT&CK detection strategy DET0093 (Behavioral Detection of User Discovery via Local and Remote Enumeration) gives one analytic per platform:
| Platform (analytic) | Behaviour | Log source in ATT&CK | Tune for |
|---|---|---|---|
| Windows (AN0254) | whoami, query user, net user or scripts enumerating users locally or through WMI and PowerShell | Sysmon Event ID 1; PowerShell events 4103 to 4106 | Non-interactive parents and system services, service accounts issuing the commands, enumeration followed by lateral movement |
| Linux (AN0255) | whoami, id, w or reading /etc/passwd from non-interactive or scripting contexts | auditd execve | Command arguments, cron, systemd or reverse shell context, expected frequency |
| macOS (AN0256) | dscl, who or $USER through Terminal or malicious LaunchAgents | Unified log (Terminal subsystem); Endpoint Security exec events | LaunchAgent correlation, terminal versus script, dscl list patterns |
| Network devices (AN0257) | show users, show ssh or attempts to dump AAA user lists | Device syslog with AAA privileged exec accounting | Expected commands per device and user role, burst use of show commands |
Detection rules to build
These rules are NHI Mgmt Group recommendations. The first four extend DET0093; the last three cover the cloud self-check.
| Rule | Logic | Fidelity |
|---|---|---|
| Suspicious parent | whoami or id whose parent is a web server worker, database engine, Office application, Java process or script host | High |
| Service account shell | User discovery commands run under a service account, application pool identity or workload identity | High |
| Session hunting | quser or query user run remotely, or against many hosts in a short window | Medium to high |
| Bulk logon event read | A process other than your log forwarder or SIEM agent reading Security Event ID 4624 records in bulk | High |
| Self-check from a new network | CloudTrail GetCallerIdentity by an access key or role session from a source IP or ASN never seen for that identity | High for machine identities |
| Self-check with a new user agent | GetCallerIdentity from a user agent the identity has never used (for example a CLI on a key that normally only calls from an SDK in one application) | Medium to high |
| Validation-only key | A long-dormant access key whose first call in weeks is GetCallerIdentity, with or without follow-on listing calls | High |
To make the cloud rules work, keep a per-identity baseline of source networks, user agents and API calls, and query both the US East (N. Virginia) Region (global STS endpoint) and the regional trails. See the AWS CloudTrail Guide and How to Detect aws access key use from unusual locations.
Where identity fits
This technique is identity discovery by definition, and non-human identities are where detection is easiest. A human account legitimately runs whoami from many contexts; a service account or CI key does not. Three practices make that advantage real:
- One identity per workload: shared keys make baselines meaningless. See the AWS Access Keys Security Guide.
- Short-lived credentials: a stolen temporary credential that expires in an hour gives the attacker little time after the self-check.
- Canary credentials: a decoy access key that no workload uses turns any self-check into a confirmed alert. See the Honeytokens and Canary Credentials Guide.
Reducing exposure
ATT&CK states that T1033 cannot be easily mitigated with preventive controls because it abuses system features. These controls, NHI Mgmt Group recommendations, limit what the answer gives an attacker:
| Control | Effect |
|---|---|
| Remove standing admin sessions | Session discovery finds no privileged users to target; use just-in-time elevation and log off admin sessions |
| Least privilege for service accounts | When the self-check returns a service account, its rights are narrow |
| Restrict Security log access | Only log forwarders and administrators can read logon events |
| Source restrictions on machine credentials | Network conditions in cloud policies stop a stolen key from doing more than the self-check, which is still logged |
| Secret scanning and rotation | Fewer valid keys exist to be validated; see MITRE ATT&CK T1552 Unsecured Credentials Guide |
How to test and roll out
- Check telemetry: process creation with command lines and parents on endpoints and servers, PowerShell script block logging, auditd, device AAA accounting, and CloudTrail management events in every Region including US East (N. Virginia).
- Emulate safely: in an authorised test, run user discovery from an admin shell, from a service account scheduled task and from a child of a test web server process. In a sandbox AWS account, call GetCallerIdentity with a test key from a new network and a new user agent.
- Verify the alert content: each alert should name the parent, identity, source IP and user agent.
- Run in alert-only mode for two weeks: exclude monitoring agents and deployment pipelines by identity and source, not by command name.
- Promote the high-fidelity rules first (suspicious parent, service account shell, self-check from a new network). If volume spikes, return the rule to alert-only rather than deleting it.
Measuring progress
- Percentage of machine identities with a recorded baseline of source networks and user agents.
- Number of access keys shared by more than one workload (target: zero).
- Median time from a self-check alert to key disablement or session revocation.
- Percentage of hosts sending process creation with parent details.
- Number of canary credentials deployed and tested in the last quarter.
Common failure patterns
- Alerting on whoami everywhere: the rule floods and is disabled; alert on parent and identity instead.
- Trying to deny GetCallerIdentity: AWS documents that an explicit deny does not stop it, so the policy only gives false comfort.
- Watching one Region: global STS endpoint calls land in US East (N. Virginia), so a detection scoped to your home Region misses them.
- Shared CI keys: many pipelines on one key make every new source look normal.
- Treating a lone self-check as harmless: a validation-only call often means the key is about to be sold or used; rotate it.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | T1033; tactic TA0007; DET0093 | Technique and detection strategy |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring; AU-6 Audit Record Review, Analysis, and Reporting; AU-12 Audit Record Generation | Host and cloud audit telemetry |
| NIST SP 800-53 Rev 5 | AC-2 Account Management; AC-6 Least Privilege; IA-4 Identifier Management | One identity per workload, scoped rights |
| NIST CSF 2.0 | DE.CM-09; DE.AE-02; PR.AA-05 | Monitoring, analysis, least privilege |
| ISO/IEC 27001:2022 Annex A | A.5.16 Identity management; A.8.15 Logging; A.8.16 Monitoring activities | Identity lifecycle and monitoring |
Practitioner checklist
- Alert on user discovery commands spawned by server, Office and script host processes.
- Alert on user discovery commands run by service accounts and workload identities.
- Detect remote
quserand bulk reads of logon events. - Collect CloudTrail in all Regions and include the global STS endpoint events.
- Baseline source networks and user agents per machine identity and alert on new ones.
- Give every workload its own credential and prefer short-lived ones.
- Deploy and test canary access keys.
- Rotate any key whose only recent activity is a self-check.
Standards and references
- MITRE ATT&CK: System Owner/User Discovery (T1033)
- AWS: GetCallerIdentity API reference
- AWS: Logging IAM and AWS STS API calls with CloudTrail
- Google Cloud: gcloud auth list
- Microsoft: az account command reference
- Microsoft: Sign-in logs in Microsoft Entra ID
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: T1087 and T1069 Account and Permission Group Discovery Defensive Guide · MITRE ATT&CK T1078 Valid Accounts Guide · How to Investigate CloudTrail for a Compromised Access Key · Stolen credential breaches