Logged-on user identity queried by a built-in enumeration tool

Siemphony@siemphonylowT1033verified in labPlaybook · Discovery and enumeration

AN0254 describes an adversary running the shipped tools that answer "who am I and who else is on this box" — the analytic names `whoami`, `query user` and `net user` — so each leg here anchors on one of those and on the API-level equivalents that avoid the executables. What MITRE says separates reconnaissance from routine use lives entirely in its tuning knobs: ParentProcessContext (enumeration from a non-interactive shell or service), UserContext (a service account issuing the command) and TimeWindow (grouping the query with lateral movement that follows). Sigma models no timeframe and no per-user baseline, so none of the three is encoded and the rule is left matching the single-event precursor, which is why the level sits near the bottom of the scale rather than in the middle. Two limits worth stating: the `net user` leg overlaps local account enumeration and will fire on that as well, and AN0254's other log source — the PowerShell 4103/4104 channel — is not used, so a cmdlet or `whoami` typed into a session that is already running creates no process and is invisible here. This is Sysmon EventID 1 telemetry; confirm process creation is not filtered out of the running Sysmon config before reading an empty result as quiet rather than blind. Three of the five legs test `CommandLine`, so if the `process_creation` index is fed from Security 4688 instead they need the separate *Include command line in process creation events* policy, which is off in a default install and in the MS/CIS baselines; without it the `whoami` and `quser` legs still fire and the rule looks healthy while three of five are silently dead. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0093, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

1title: Logged-on user identity queried by a built-in enumeration tool2id: 51878ce4-6986-4b37-b1af-613b14d0461f3status: experimental4description: |5  AN0254 describes an adversary running the shipped tools that answer "who am I6  and who else is on this box" — the analytic names `whoami`, `query user` and7  `net user` — so each leg here anchors on one of those and on the API-level8  equivalents that avoid the executables. What MITRE says separates9  reconnaissance from routine use lives entirely in its tuning knobs:10  ParentProcessContext (enumeration from a non-interactive shell or service),11  UserContext (a service account issuing the command) and TimeWindow (grouping12  the query with lateral movement that follows). Sigma models no timeframe and13  no per-user baseline, so none of the three is encoded and the rule is left14  matching the single-event precursor, which is why the level sits near the15  bottom of the scale rather than in the middle. Two limits worth stating: the16  `net user` leg overlaps local account enumeration and will fire on that as17  well, and AN0254's other log source — the PowerShell 4103/4104 channel — is18  not used, so a cmdlet or `whoami` typed into a session that is already running19  creates no process and is invisible here. This is Sysmon EventID 1 telemetry;20  confirm process creation is not filtered out of the running Sysmon config21  before reading an empty result as quiet rather than blind. Three of the five22  legs test `CommandLine`, so if the `process_creation` index is fed from23  Security 4688 instead they need the separate *Include command line in process24  creation events* policy, which is off in a default install and in the MS/CIS25  baselines; without it the `whoami` and `quser` legs still fire and the rule26  looks healthy while three of five are silently dead.27  UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0093, not hand-written and not tested by its author. Any lab result is on this rule's own page.28references:29  - https://attack.mitre.org/techniques/T103330  - https://attack.mitre.org/detectionstrategies/DET009331author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)32date: 2026-08-1633tags:34  - attack.discovery35  - attack.t103336logsource:37  category: process_creation38  product: windows39detection:40  selection_whoami:41    Image|endswith: '\whoami.exe'42  selection_session_tool:43    Image|endswith:44      - '\quser.exe'45      - '\qwinsta.exe'46  selection_query_verb:47    Image|endswith: '\query.exe'48    CommandLine|contains:49      - ' user'50      - ' session'51  selection_net_user:52    Image|endswith:53      - '\net.exe'54      - '\net1.exe'55    CommandLine|contains: ' user'56  selection_api_identity:57    CommandLine|contains:58      - 'WindowsIdentity]::GetCurrent'59      - 'Environment]::UserName'60      - '$env:USERNAME'61      - 'Win32_LoggedOnUser'62  condition: 1 of selection*63falsepositives:64  - "Logon scripts and endpoint-management tooling that call whoami.exe to branch on the account running them. On a managed estate this fires at every interactive logon and on every agent check-in, and is the highest-volume match by a wide margin — MITRE's UserContext knob is the place to suppress it, keyed on the agent's service account."65  - "Helpdesk and remote-desktop administration on session hosts, where query user or quser is the normal way to find which session to shadow, reset or log off before maintenance."66  - "Administrators running net user against a named account to check password expiry, group membership or lockout state during ordinary account support."67  - "Backup, licensing and monitoring agents that read the current identity through $env:USERNAME or WindowsIdentity to stamp it into their own records, producing a steady low-rate match on healthy hosts."68level: low

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where (FolderPath endswith "\\whoami.exe" or (FolderPath endswith "\\quser.exe" or FolderPath endswith "\\qwinsta.exe") or (FolderPath endswith "\\query.exe" and (ProcessCommandLine contains " user" or ProcessCommandLine contains " session")) or ((FolderPath endswith "\\net.exe" or FolderPath endswith "\\net1.exe") and ProcessCommandLine contains " user") or (ProcessCommandLine contains "WindowsIdentity]::GetCurrent" or ProcessCommandLine contains "Environment]::UserName" or ProcessCommandLine contains "$env:USERNAME" or ProcessCommandLine contains "Win32_LoggedOnUser"))

Splunk · SPL

Run this as a search.

index=* (Image="*\\whoami.exe" OR (Image="*\\quser.exe" OR Image="*\\qwinsta.exe") OR (Image="*\\query.exe" AND (CommandLine="* user*" OR CommandLine="* session*")) OR ((Image="*\\net.exe" OR Image="*\\net1.exe") AND CommandLine="* user*") OR (CommandLine="*WindowsIdentity]::GetCurrent*" OR CommandLine="*Environment]::UserName*" OR CommandLine="*$env:USERNAME*" OR CommandLine="*Win32_LoggedOnUser*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(process.executable) LIKE "*\\\\whoami.exe" OR (TO_LOWER(process.executable) LIKE "*\\\\quser.exe" OR TO_LOWER(process.executable) LIKE "*\\\\qwinsta.exe") OR (TO_LOWER(process.executable) LIKE "*\\\\query.exe" AND (TO_LOWER(process.command_line) LIKE "* user*" OR TO_LOWER(process.command_line) LIKE "* session*")) OR ((TO_LOWER(process.executable) LIKE "*\\\\net.exe" OR TO_LOWER(process.executable) LIKE "*\\\\net1.exe") AND TO_LOWER(process.command_line) LIKE "* user*") OR (TO_LOWER(process.command_line) LIKE "*windowsidentity]::getcurrent*" OR TO_LOWER(process.command_line) LIKE "*environment]::username*" OR TO_LOWER(process.command_line) LIKE "*$env:username*" OR TO_LOWER(process.command_line) LIKE "*win32_loggedonuser*"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,process_creation,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 5 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)\\whoami\.exe$</field>    <description>Logged-on user identity queried by a built-in enumeration tool (1/5)</description>    <mitre>      <id>T1033</id>    </mitre>  </rule>   <rule id="100001" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)(\\quser\.exe$|\\qwinsta\.exe$)</field>    <description>Logged-on user identity queried by a built-in enumeration tool (2/5)</description>    <mitre>      <id>T1033</id>    </mitre>  </rule>   <rule id="100002" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)\\query\.exe$</field>    <field name="CommandLine" type="pcre2">(?i)( user| session)</field>    <description>Logged-on user identity queried by a built-in enumeration tool (3/5)</description>    <mitre>      <id>T1033</id>    </mitre>  </rule>   <rule id="100003" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)(\\net\.exe$|\\net1\.exe$)</field>    <field name="CommandLine" type="pcre2">(?i) user</field>    <description>Logged-on user identity queried by a built-in enumeration tool (4/5)</description>    <mitre>      <id>T1033</id>    </mitre>  </rule>   <rule id="100004" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="CommandLine" type="pcre2">(?i)(WindowsIdentity\]::GetCurrent|Environment\]::UserName|\$env:USERNAME|Win32_LoggedOnUser)</field>    <description>Logged-on user identity queried by a built-in enumeration tool (5/5)</description>    <mitre>      <id>T1033</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: low
Category: discovery_recon
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 51878ce4-6986-4b37-b1af-613b14d0461f

ATT&CKT1033

T1033System Owner/User Discovery

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Evidence

Verification2 runs

Verified in Siemphony lab

Security Datasets — System owner and user discovery
passed
Siemphony IR · 3 Sept 2026
10 true · 0 false · 0.0% noise
Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
0 true · 2 false · 100.0% noise

Noise checkfires on 2 of 30

Fires on 2 of 30 ordinary behaviours the baseline holds for this log type. Each is something a managed estate does on purpose, so each is a false positive an analyst would have to close.

pc-helpdesk-net-user-domain
Helpdesk checking an account before a password reset. `net user /domain` is a support routine and a discovery technique at once.
pc-helpdesk-whoami-groups
Support staff confirming their own effective group membership during a permissions ticket.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1033, evaluated against their process_creation events.

Using it

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Do not deploy this as an alert. Route it to a hunting index and use it as context that enriches a real detection. If you must alert, implement MITRE's knobs in your platform: suppress on UserContext keyed to the management agent's service account, and promote severity only when ParentProcessContext shows a non-interactive or unexpected parent — an Office application, a script host, a web service account.

Declared by the author

Logon scripts and endpoint-management tooling that call whoami.exe to branch on the account running them. On a managed estate this fires at every interactive logon and on every agent check-in, and is the highest-volume match by a wide margin — MITRE's UserContext knob is the place to suppress it, keyed on the agent's service account.
Helpdesk and remote-desktop administration on session hosts, where query user or quser is the normal way to find which session to shadow, reset or log off before maintenance.
Administrators running net user against a named account to check password expiry, group membership or lockout state during ordinary account support.
Backup, licensing and monitoring agents that read the current identity through $env:USERNAME or WindowsIdentity to stamp it into their own records, producing a steady low-rate match on healthy hosts.

Lessondiscovery recon

discovery reconAI draft — unreviewed

01 · What this rule detects

Built-in Windows tools being run to answer "who am I, and who else is on this box". MITRE's AN0254 names whoami, query user and net user explicitly, and each leg of this rule anchors on one of those, plus the API-level equivalents that skip the executables entirely. It is a single-event precursor: the rule sees the question being asked, not what the answer was used for.

02 · Telemetry you need

logsource: category: process_creation, product: windows, taken verbatim from the brief — Sysmon EventID 1 in practice. Confirm process creation is not filtered out of the running Sysmon configuration before reading an empty result as quiet rather than blind. Three of the five legs test CommandLine, so if your process_creation index is fed from Security 4688 instead, you need Audit Process Creation plus the separate Include command line in process creation events policy. Neither is on by default nor in the MS/CIS baselines. Without the command-line policy the whoami and quser legs still fire, so the rule looks healthy while three of its five legs are silently dead — the worst kind of partial blindness.

03 · How the logic works

selection_whoami is Image|endswith: '\whoami.exe', alone — no argument test, because bare whoami is the interesting case. selection_session_tool matches quser.exe and qwinsta.exe, the shortcut binaries for session listing. selection_query_verb covers the long form: Image|endswith: '\query.exe' AND a CommandLine containing ' user' or ' session'. The leading space matters — it keeps the term bound to the verb position rather than matching anywhere. selection_net_user requires net.exe or net1.exe AND ' user' on the command line. net1.exe is included because net.exe silently hands off to it, and a rule that names only the first misses the child. selection_api_identity is the scripted route: WindowsIdentity]::GetCurrent, Environment]::UserName, $env:USERNAME and Win32_LoggedOnUser on the command line. These are the API calls the analytic mentions as an alternative to the executables. The strings are authored here, not MITRE's list. Condition is 1 of selection*. The important thing to understand is what is missing. Everything MITRE says separates reconnaissance from routine use lives in its tuning knobs: ParentProcessContext (enumeration from a non-interactive shell or service), UserContext (a service account issuing the command) and TimeWindow (grouping the query with lateral movement that follows). Sigma models no timeframe and no per-user baseline, so none of the three is encoded. The rule is the raw precursor with the discriminating context stripped out, which is exactly why the level sits at low rather than in the middle. Two further limits: the net user leg overlaps local account enumeration (T1087) and will fire on that too, and AN0254's PowerShell 4103/4104 log source is unused, so a cmdlet or whoami typed into an already-running session creates no process and is invisible here.

04 · Common false positives

Constantly. Logon scripts and endpoint-management agents call whoami.exe to branch on the account running them — that fires at every interactive logon and every agent check-in, and is the highest-volume match by a wide margin. Helpdesk staff run quser on session hosts to find which session to reset. Admins run net user <account> to check password expiry. Backup and monitoring agents read $env:USERNAME to stamp their own records.

05 · Detection maturity

tier_1: Lowest tier. Machine-derived from ATT&CK v19.2 and never run against real data, with three of its five legs dependent on a policy that is off by default. It cannot advance until the volume is measured on a live estate.

Related detections3 nearby

Ranked by how alike the detection logic reads, computed offline. Proximity is not evidence — each of these carries its own verification state on its own page.

Share this rule

/u/siemphony/51878ce4-6986-4b37-b1af-613b14d0461f

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Logged-on user identity queried by a built-in enumeration tool

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it