Overview

System Owner/User Discovery (T1033) is a reconnaissance technique where adversaries enumerate the current user, active sessions, and account listings on a compromised host. Attackers use this information to understand the value of the system they have landed on — determining whether they are running as a privileged account, whether a human user is actively present, and whether the environment is worth further exploitation.

Every security team needs to detect this technique because it is a near-universal step in the early post-exploitation phase — appearing in ransomware pre-deployment, APT lateral movement, and commodity malware alike. Catching T1033 activity early, before attackers act on what they learn, is one of the highest-leverage opportunities to interrupt an intrusion in progress.

Attacker Perspective

After gaining initial access, adversaries immediately orient themselves by discovering who owns the system and what privileges they have inherited.

• Interactive shell reconnaissance (Windows): Attackers running a Cobalt Strike beacon or Meterpreter session execute whoami /all and query user directly from the implant’s shell to identify privilege level and active RDP sessions before deciding whether to attempt a UAC bypass.
• Automated discovery scripts (Linux/macOS): Post-exploitation frameworks like Metasploit’s post/multi/recon/local_exploit_suggester and custom bash stagers run id, w, who, and cat /etc/passwd in rapid succession as part of automated host profiling within seconds of landing.
• Living-off-the-land enumeration (Windows): Threat actors using only built-in tools chain whoami, net user, net localgroup administrators, and environment variable inspection (echo %USERNAME%, echo %USERDOMAIN%) to avoid dropping any additional tooling that might trigger AV.
• Network device targeting: Adversaries who have compromised a network device (router, switch) via stolen credentials or a known CVE run CLI commands such as show users, show ssh, and show run | include username on Cisco IOS to enumerate administrative accounts and active management sessions before pivoting.

This technique is attractive to attackers precisely because it uses built-in OS utilities that are present on every platform, generate minimal noise in default logging configurations, and directly answer the questions that drive every subsequent decision in the kill chain.

Detection Strategy

Required Telemetry

• Windows — Process Creation (Event ID 4688): Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation. Set to Success. Additionally enable command-line logging in process creation events via GPO: Administrative Templates → System → Audit Process Creation → Include command line in process creation events = Enabled. This populates the CommandLine field in Event ID 4688.
• Windows — Sysmon Process Creation (Event ID 1): Deploy Sysmon with a configuration that captures CommandLine, ParentImage, ParentCommandLine, User, and IntegrityLevel for all process creation events. This is far richer than native 4688 and should be preferred where Sysmon is deployed. Use the SwiftOnSecurity or Olaf Hartong Sysmon configuration as a baseline.
• Windows — PowerShell Script Block Logging (Event ID 4104): Enable via GPO or registry: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. This captures deobfuscated PowerShell content including commands like [System.Environment]::UserName or $env:USERNAME that would otherwise be invisible.
• Windows — Security Logon/Session Events: Event ID 4624 (successful logon) and 4634 (logoff) provide session context. Enable via Audit Logon Events → Success and Failure. Event ID 4648 (logon with explicit credentials) is valuable for detecting lateral movement following discovery.
• Linux — Auditd Process Execution: Add the following rules to /etc/audit/rules.d/audit.rules to capture execution of discovery commands:
  -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/whoami -k user_discovery
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/w -k user_discovery
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/who -k user_discovery
-a always,exit -F arch=b64 -S execve -F exe=/bin/id -k user_discovery
  These generate EXECVE and SYSCALL audit records tagged with the key user_discovery.
• Linux — Auditd File Read (passwd/shadow): Add rules to flag reads of sensitive account files:
  -a always,exit -F arch=b64 -S open,openat -F path=/etc/passwd -F perm=r -k passwd_read
-a always,exit -F arch=b64 -S open,openat -F path=/etc/shadow -F perm=r -k shadow_read
• macOS — Endpoint Security Framework / EDR telemetry: Native macOS does not generate robust process creation logs without an EDR agent or the Endpoint Security Framework. Ensure your EDR (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) is enrolled and reporting process execution events including process.name, process.command_line, and process.parent.name. Unified Log entries for sudo and dscl are available via log stream --predicate 'process == "dscl"' but require active collection.
• Network Devices — Syslog / AAA Logging: Configure all managed network devices to send syslog (facility local6 or local7) and AAA accounting records to your SIEM. On Cisco IOS: logging host <SIEM_IP>, aaa accounting commands 15 default start-stop group tacacs+. This captures show users and show ssh commands run under privileged mode.
• EDR Telemetry (all platforms): If available, EDR process trees (CrowdStrike Falcon, Microsoft Defender for Endpoint, Carbon Black) provide the most reliable cross-platform source for this technique, including parent-child relationships and command-line arguments. Prioritise EDR over native OS logs where both are available.

Key Indicators

• Suspicious process — whoami with privilege flags (Windows): Log source: Sysmon Event ID 1 or Security Event ID 4688. Field: CommandLine. Pattern: whoami /all, whoami /priv, whoami /groups. A plain whoami alone is low signal; the addition of /all or /priv strongly suggests adversarial reconnaissance of privilege level.
• Suspicious parent process (Windows): Log source: Sysmon Event ID 1. Fields: ParentImage and Image. Flag when Image contains whoami.exe, net.exe, or query.exe AND ParentImage is an unusual parent such as cmd.exe spawned by mshta.exe, wscript.exe, cscript.exe, powershell.exe, rundll32.exe, or any Office application.
• Rapid sequential execution of discovery commands (all platforms): Log source: Sysmon Event ID 1 or auditd EXECVE records. Look for three or more of the following commands executing within a 60-second window on the same host under the same user session: whoami, net user, net localgroup, query user, id, w, who, dscl. This burst pattern is characteristic of automated post-exploitation frameworks.
• Environment variable enumeration via PowerShell (Windows): Log source: PowerShell Event ID 4104. Field: ScriptBlockText. Patterns: $env:USERNAME, $env:USERDOMAIN, [System.Environment]::UserName, [System.Security.Principal.WindowsIdentity]::GetCurrent(). Legitimate admin scripts rarely call these in isolation; flag when they appear without surrounding business-logic context.
• cat /etc/passwd or /etc/shadow access (Linux): Log source: auditd SYSCALL + PATH records with key passwd_read or shadow_read. Field: comm (command name) and exe (full executable path). Flag when exe is /bin/cat, /usr/bin/less, or a script interpreter and the accessed path is /etc/passwd or /etc/shadow. Shadow reads by anything other than passwd, su, or sudo are nearly always suspicious.
• dscl enumeration (macOS): Log source: EDR process execution telemetry. Field: process.command_line. Pattern: dscl . list /Users, especially when piped through grep -v '_' to filter out system accounts. This specific pattern appears verbatim in the MITRE ATT&CK description and in multiple macOS-targeting malware families.
• Network device CLI — show commands (Network Devices): Log source: Syslog or TACACS+ accounting records. Field: message text or command field. Patterns: show users, show ssh, show run | include username executed outside of a known maintenance window or from an unexpected source IP. Cross-reference the source IP against known admin jump hosts.
• query user / quser execution (Windows): Log source: Sysmon Event ID 1. Field: Image. Value: C:\Windows\System32\quser.exe or query.exe with CommandLine containing user. This command lists all logged-on users and is rarely needed by end users; execution outside IT admin accounts warrants review.

Detection Logic

Rule 1 — Broad: Any execution of known user discovery binaries
IF process.name IN ["whoami.exe", "quser.exe", "query.exe", "net.exe", "w", "who", "id", "dscl"] AND event.type = "process_start" AND NOT user IN [trusted_admin_accounts] AND NOT parent_process.name IN ["sccm.exe", "chef-client", "puppet"] THEN alert(severity=LOW)

This catch-all rule fires on any execution of primary discovery binaries. Expected volume is high in most environments — this rule is most useful as a data source for the chaining rules below, and on its own should be treated as informational or used to build a baseline of normal behaviour rather than as an actionable alert.

Rule 2 — Medium: User discovery with suspicious parent process
IF process.name IN ["whoami.exe", "quser.exe", "net.exe", "query.exe"] AND parent_process.name IN ["powershell.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "excel.exe", "winword.exe", "outlook.exe"] AND event.type = "process_start" THEN alert(severity=MEDIUM)

This rule catches discovery commands launched from scripting engines or Office applications — a reliable indicator of a phishing payload or macro-based implant performing post-compromise reconnaissance. Expected volume is low to medium; Office parent processes in particular are high-fidelity.

Rule 3 — High precision: Discovery command burst within 60 seconds
IF COUNT(process.name IN ["whoami.exe", "net.exe", "quser.exe", "query.exe", "ipconfig.exe", "systeminfo.exe", "tasklist.exe", "nltest.exe"]) >= 3 WITHIN 60 seconds WHERE host.name = same AND user.name = same AND NOT user IN [known_it_admin_accounts] THEN alert(severity=HIGH)

This rule detects the automated discovery burst characteristic of frameworks like Cobalt Strike, Metasploit, and Empire, which run a reconnaissance script immediately after initial access. A single human operator rarely runs three or more of these commands in under a minute. Expected volume is very low and almost every hit warrants investigation.

Rule 4 — High precision: Privileged whoami or PowerShell identity check
IF (process.command_line CONTAINS "whoami /all" OR process.command_line CONTAINS "whoami /priv" OR script_block_text CONTAINS "[System.Security.Principal.WindowsIdentity]::GetCurrent()" OR script_block_text CONTAINS "$env:USERNAME") AND NOT process.parent.name IN ["devenv.exe", "code.exe", "jenkins.exe", "build_agent"] AND NOT user IN [known_developer_accounts] THEN alert(severity=HIGH)

This rule specifically catches privilege-probing behaviour. The whoami /all flag is almost never run by legitimate end users and is a strong indicator of an attacker checking whether they have administrative or SYSTEM-level access before proceeding. Expected volume is very low with minimal false positives outside of developer build pipelines.

Tuning Guidance

• IT administration tooling: Systems management platforms (SCCM, Ansible, Chef, Puppet, SolarWinds) routinely execute whoami, net user, and id as part of inventory or compliance checks. Identify the service accounts and parent process names used by these tools and add them as exclusions: user IN [svc_sccm, svc_ansible] or parent_process.name IN ["ccmexec.exe", "ansible-runner"].
• Developer and build environments: CI/CD pipelines (Jenkins, GitHub Actions runners, Azure DevOps agents) frequently call whoami and environment variable checks as part of build scripts. Exclude by host group (tag build agents separately in your CMDB) or by service account: host.role = "build_agent" OR user IN [svc_jenkins, svc_azdevops].
• Security and vulnerability scanning tools: Authenticated vulnerability scanners (Tenable Nessus, Qualys, Rapid7 InsightVM) will trigger discovery rules during scheduled scans. Create time-window exclusions aligned to your scan schedules or exclude by the scanner’s service account and source IP range: user = "svc_nessus" AND source.ip IN [scanner_subnet].
• Legitimate administrative activity: Help desk staff and system administrators legitimately run query user and whoami when troubleshooting session issues. Build a baseline of normal admin behaviour by host and time of day. Suppress alerts for known admin accounts operating during business hours from their registered workstations: user IN [helpdesk_group] AND hour_of_day BETWEEN 8 AND 18 AND host.name = user.primary_workstation.
• Linux cron jobs and startup scripts: Many Linux applications and init scripts call id or whoami at startup to verify they are running under the expected user. Review auditd hits against /etc/cron.d/, systemd unit files, and application init scripts. Suppress by ppid matching known init processes: parent_process.name IN ["systemd", "crond", "init"] where the calling user matches the expected service account.

When the Alert Fires: Investigation Steps

1. Verify the alert is real and pull the raw event. Navigate directly to the originating log source (Sysmon Event ID 1, auditd EXECVE record, or EDR process event) and confirm the raw event exists with all expected fields populated — do not rely solely on the SIEM-parsed alert, as field extraction errors can cause false positives. Record the exact timestamp, hostname, username, process GUID, and full command-line string.
2. Identify the affected host and user — flag privilege level immediately. Look up the user account in Active Directory (or your IdAM) and confirm whether it is a standard user, local admin, domain admin, or service account. If the account has elevated privileges or the process ran with IntegrityLevel = High or System (visible in Sysmon Event ID 1), escalate severity immediately and move faster on all subsequent steps.
3. Reconstruct the full parent process chain going back at least three generations. In Sysmon, correlate using ProcessGuid and ParentProcessGuid fields across Event ID 1 records on the same host. In an EDR console, use the process tree view. You are looking for anomalous parents — a browser, Office application, or script interpreter spawning cmd.exe which then spawns whoami.exe is highly suspicious and may indicate a phishing payload or browser exploit.
4. Check for network connections made by the process or its parent around the same time. Query Sysmon Event ID 3 (Network Connection) or EDR network telemetry for connections originating from the suspicious process or its parent within ±5 minutes of the discovery event. Beacon-like connections to external IPs or domains — especially on non-standard ports or using uncommon user-agents — indicate an active C2 channel. Also check DNS Event ID 22 (Sysmon) for any domain lookups made at the same time.
5. Search for files written to disk immediately before or after the discovery event. Query Sysmon Event ID 11 (FileCreate) and Event ID 15 (FileCreateStreamHash) on the affected host for the ±10-minute window around the alert time. Look for executables, scripts, or archive files dropped in unusual locations: %TEMP%, %APPDATA%, C:\ProgramData, /tmp, /var/tmp. Hash any findings and check against VirusTotal or your threat intel platform immediately.
6. Look for lateral movement originating from this host after the discovery event. Query your authentication logs for Event ID 4648 (logon with explicit credentials) and Event ID 4624 Type 3 (network logon) originating from the affected host in the hours following the alert. In Microsoft Sentinel or Splunk, pivot on source.host = affected_host in authentication and network flow data. Any successful authentication to other internal hosts — especially servers, domain controllers, or file shares — should be treated as confirmed lateral movement.
7. Make the escalation decision: confirmed incident or benign? Escalate to a confirmed incident if any of the following are true: the discovery command was spawned by a suspicious parent (Office, browser, script engine); the user account has no business reason to run the command; a network connection to an external IP was observed within the same session; file drops or lateral movement were found; or the command was one of three or more discovery commands run in rapid succession. If none of these conditions are met and the activity matches a known legitimate tool or admin account, document the finding, add a tuning exclusion, and close as a false positive.

Response Playbook

Containment

• Isolate the affected host — leave it powered on. Use your EDR console (CrowdStrike Network Containment, Microsoft Defender for Endpoint Isolate Device, Carbon Black Quarantine Device) to cut network access while preserving the live forensic state. Do not power off the machine — volatile memory (running processes, active network connections, decrypted credentials) is critical evidence. Label the host in your CMDB as “under investigation.”
• Disable the affected user account — do not just reset the password yet. In Active Directory, use Disable-ADAccount -Identity <username> or the AD Users and Computers console. Disabling the account prevents re-authentication even if the attacker has cached credentials; a password reset alone does not invalidate existing Kerberos tickets.
• Revoke active sessions and Kerberos tickets for the affected account. Run klist purge on the affected host (if accessible) and use Invoke-ADServiceAccountPasswordReset or force a ticket purge via nltest /sc_reset:<domain>. In Azure AD environments, use the Microsoft Graph API or Entra ID portal to revoke all refresh tokens: Azure AD → User → Revoke sessions.
• Block identified C2 IPs and domains at the perimeter. If investigation Step 4 identified suspicious outbound connections, submit the IPs and domains to your firewall team and DNS security platform (Cisco Umbrella, Palo Alto DNS Security, or BIND RPZ) for immediate blocking. Document all blocked indicators in your ticketing system with the justification and timestamp.
• Kill any identified malicious processes on the host. Using your EDR’s remote response capability, terminate processes identified as malicious. In CrowdStrike RTR: kill <pid>. In Defender for Endpoint Live Response: run killprocess.exe <pid>. Terminate the full process tree, not just the leaf process, to ensure the parent implant is also stopped.

Eradication

• Remove identified persistence mechanisms. Based on your investigation findings, check and clean the following locations: scheduled tasks (schtasks /query /fo LIST /v), registry run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run, HKLM\Software\Microsoft\Windows\CurrentVersion\Run), new or modified services (sc query type= all state= all), and WMI subscriptions (Get-WMIObject -Namespace root\subscription -Class __EventFilter). On Linux, audit crontabs, /etc/rc.local, and systemd unit files in /etc/systemd/system/.
• Find and delete all dropped payloads and tools. Use file hashes from Sysmon Event ID 11 or EDR file creation events to locate all copies of dropped files across the environment — run a hash-based hunt across all endpoints via your EDR console. Delete identified files and verify deletion with a follow-up query. Submit all unique hashes to your threat intel platform and add them to your EDR blocklist.
• Reset credentials for all accounts that executed or were exposed to the malicious activity. Reset passwords for the affected user account and any other accounts that authenticated to the host during the incident window (visible in Event ID 4624 logs). If the host held cached domain credentials or a secrets manager agent, treat all cached credentials as compromised and reset them proactively.
• Check all lateral movement targets for backdoors. For every host that received an inbound connection from the affected machine after the discovery event (identified in Step 6), run an EDR triage scan and review process creation logs for the same timeframe. Look for the same IOCs — dropped files, suspicious processes, new scheduled tasks — that were found on the primary host.
• Rotate any secrets, API keys, or service account credentials that may have been visible on the host. Review what credentials were stored or recently used on the compromised host (browser saved passwords, credential manager, environment variables, application config files). Rotate all of them. If cloud service credentials (AWS access keys, Azure service principal secrets) were present, rotate via the cloud console and audit CloudTrail or Azure Activity Logs for any usage of those credentials during the incident window.

Recovery

• Re-image before reconnecting — unless forensic confidence is very high. If there is any doubt about whether all persistence mechanisms have been found, re-image the host from a known-good golden image rather than attempting to clean it in place. The time cost of re-imaging is always lower than the cost of a re-infection. Restore user data from a backup taken prior to the initial compromise date.
• Re-enable the user account only after confirming no persistence remains. Before re-enabling the account in Active Directory, confirm that all persistence mechanisms have been removed, all malicious files deleted, and all credentials rotated. Brief the user on what happened (at an appropriate level of detail) and instruct them to report any unusual activity immediately.
• Monitor the previously affected host and user account intensively for 72 hours post-remediation. Create a temporary high-sensitivity detection rule in your SIEM scoped specifically to the affected host and user for 72 hours. Set lower thresholds for the same T1033 indicators, and also watch for any re-execution of the same discovery commands, new outbound connections, or re-appearance of the same file hashes.
• Document the full incident timeline and produce a written post-incident report. Record the initial alert time, each investigation finding with supporting log evidence, every containment and eradication action taken, and the final root cause determination. This timeline is essential for any regulatory notification obligations and for the lessons-learned review.
• Update detection rules and threat intelligence with newly discovered IOCs. Add all confirmed malicious file hashes, C2 IPs, domains, and command-line patterns discovered during the investigation to your SIEM detection rules, EDR blocklist, and threat intel platform. If the root cause was a phishing email, submit the sender and indicators to your email security platform