Almost every intrusion has a moment where the attacker asks the machine a simple question: who am I, and who else is here? The answer shapes what they do next.
MITRE tracks this as System Owner/User Discovery, technique T1033, in the Discovery tactic. It applies to Linux, macOS, Network Devices and Windows.
This one is different from most posts in this series. MITRE states that this kind of technique cannot be easily mitigated with preventive controls, because it abuses system features. So the work is detection and context.
How attackers use it
Adversaries try to identify the primary user, the currently logged in user, the set of users who commonly use a system, or whether someone is actively using it. MITRE says they may retrieve account usernames, or use OS Credential Dumping, and that user details show up in many places: process ownership, file and directory ownership, session information and system logs.
The results can steer what happens next. MITRE notes the information may be used during automated discovery to decide whether to fully infect a target or try specific actions.
Commands MITRE names:
- Windows.
whoami, and environment variables such as%USERNAME%. - Linux and macOS.
wandwhoshow the logged in user. On macOS,dscl . list /Users | grep -v '_'lists user accounts. The$USERvariable also works. - Network devices. CLI commands such as
show usersandshow sshshow who is logged in.
All of these are everyday administrator commands. That is the difficulty.
How to detect it
MITRE's strategy (DET0093) has one analytic per platform family:
- Windows. Built-in tools such as whoami, query user or net user, or scripts that list user accounts locally or through remote queries such as WMI and PowerShell.
- Linux. Commands such as whoami, id, w or cat /etc/passwd run from non-interactive or scripting contexts.
- macOS. dscl, who or the USER variable used from Terminal or malicious LaunchAgents.
- Network devices. CLI commands such as show users and show ssh, or attempts to dump AAA user lists from routers or switches.
The words "non-interactive" and "scripting contexts" matter. A person typing whoami is routine. whoami launched by a web server process, an office application or a service account is not.
To make that visible, you need process creation logging with parent process and command line:
- Windows. Process creation auditing (event ID 4688) with command line capture, or Sysmon event ID 1.
- Linux. auditd execve records for id, whoami, w and who, with the parent process.
- macOS. Endpoint security telemetry that records process launches and parents.
- Network devices. AAA command accounting, so that CLI commands are logged by user.
Then look at sequences instead of single commands:
- Discovery commands that arrive in a burst: whoami, then net user, then more enumeration within seconds.
- Discovery commands whose parent is an application that should never run them.
- Discovery commands right after a new logon from an unusual source.
- First time use of those commands by a given account.
How to reduce the risk
MITRE lists no preventive mitigation. Say so to your team plainly, because it changes where you spend effort:
- Do not try to block whoami. Doing so will break legitimate software and will not stop discovery, since the information is in many other places.
- Invest in logging. Command line and parent process data is the foundation.
- Limit what a foothold can reach. Least privilege and good segmentation mean knowing the username tells an attacker less.
- Use detection as an early warning. Discovery usually happens early, so an alert here can come well before damage.
Check your own environment
# Windows: is process creation auditing on, and does it capture command lines?
auditpol /get /subcategory:"Process Creation"
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled
# Linux: are audit rules loaded?
sudo auditctl -l
Questions to answer:
- Can you search for whoami, id and net user by parent process across all endpoints?
- Do servers that never need discovery commands, such as web servers, have an alert if they run them?
- Do network devices log CLI commands by user to a central system?
- How long do you keep command line data?
Quick check
Why does MITRE say this technique is hard to mitigate?
It abuses normal system features. The commands are legitimate, and the same information is available in process ownership, file ownership, session data and logs.
What context makes whoami suspicious?
Being launched from a non-interactive or scripting context, from an application that should never run it, in a burst with other discovery commands, or soon after a logon from an unusual source.
Which logs make this detectable?
Process creation logs with command lines and parent processes: Windows event 4688 or Sysmon event ID 1, auditd execve records on Linux, and command accounting on network devices.
Sources
- MITRE ATT&CK, System Owner/User Discovery (T1033)
