How T1033 system owner/user discovery shows up in an intrusion
T1033 System owner/user discovery is the technique where an adversary identifies the current user or the owner of a system, and in many cases who else is logged in. It sits under the Discovery tactic (TA0007), which MITRE describes as the adversary trying to figure out your environment. This page targets Enterprise ATT&CK version 20.0. For a SOC lead, the question is usually narrow: a host or session is behaving oddly, and the team needs to know whether someone is working out which account they are operating as and which other accounts are active.
Adversaries use T1033 to answer two practical questions after gaining a foothold. The first is who they are running as, which tells them whether they have the privileges they need or must escalate. The second is who else is on the system or the network, which helps them decide where to move next and which accounts may be worth targeting. The technique is rarely noisy on its own. It usually appears in short bursts shortly after initial access, alongside other Discovery activity such as system information, account, process, network connection or group enumeration. A single user-identification command on a workstation may be routine administration, so the signal is the sequence and the context: an unfamiliar parent process, a session that started from an unusual source, or identity checks that arrive right after a suspicious logon.
Before you build alerts, confirm with your detection engineers which ATT&CK version your rules map to and whether your sensors capture the process lineage needed to tie identity checks to their parent activity. Ask your platform owners which administrative tools legitimately perform these checks on each operating system and network device class, so that baselines are built from real administrator behavior rather than assumptions. The decisions that matter most are which hosts are high value enough to alert on any identity check from non-administrative accounts, and which sessions should be correlated with discovery activity elsewhere in the same time window.
Which telemetry reveals T1033 and which open-source collector gathers it
This table maps the data components most often tied to T1033 System Owner/User Discovery to each platform in scope, with the signal to look for and the open-source collector that gathers it. Read each row as a question to answer in the client environment: is the telemetry generated, is it collected, and is it retained long enough to investigate. The main takeaway is that process and command logging carries most of the detection value, and gaps usually sit in collection rather than in the operating system.
| Platform and data component | Signal to look for | Open-source collector and gaps to confirm |
|---|---|---|
| Linux (Process Creation, Command Execution) | Short-lived executions of identity-related utilities by service accounts or unexpected users, especially from interactive shells or remote sessions | auditd execve rules forwarded to Wazuh agents. Confirm that audit rules are loaded, that log volume is tolerated and that the agent ships them off the host |
| macOS (Process Creation, Command Execution) | Identity lookups run from non-administrative applications, scripts or remote shells outside normal management tooling | Wazuh agent with log collection for unified or system logs where supported. Confirm which macOS versions the agent supports and whether process execution is captured at the depth you need |
| Windows (Process Creation, Command Execution) | Process creation events for built-in identity commands launched from unusual parent processes, with the full command line recorded | Sysmon-style process creation logging and Windows event forwarding into Wazuh or Security Onion. Confirm that command line auditing is enabled, since the event is weak without it |
| Windows (OS API Execution) | Calls to identity APIs from processes that do not normally query user or token details | EDR-agnostic logging is limited here. Confirm whether your EDR or an open-source sensor exposes API-level telemetry, because standard event logs usually do not |
| Network devices (Command Execution via syslog) | Privileged session commands or show-style queries that report the logged-in user or session identity, issued outside change windows | Syslog from network devices into Wazuh or Security Onion. Confirm that command accounting is enabled on each vendor platform, since many devices do not log every command by default |
| Cross-platform identity context | Discovery activity that follows a new or unfamiliar logon, correlated by host and session | Wazuh and Security Onion correlation on logon events. Confirm that authentication logs from every host class reach the same SIEM with synchronized clocks |
| Retention and forwarding | Enough history to baseline normal administrative identity queries per host and per role | Log forwarders and Security Onion storage. Confirm retention periods with your own policy and compliance owner, since no retention figure is set here |
Detection logic for T1033 that SOC teams can tune
The four to six ideas below describe where identity queries become suspicious enough to investigate. Each one pairs a telemetry source with a context question: who or what ran the query, and does that match how the host is normally used. Thresholds and allow-lists are starting points that you should baseline against your own estimates of normal behavior before alerting.
Identity queries from unexpected parents
Alert on user identity commands such as whoami or id when the parent process is a document reader, browser, script host, or application server worker rather than an interactive shell or a known management agent. Process creation telemetry is the primary source, so check parent image, parent command line, and whether the child runs under a user session that normally never queries identity. Set the rule to fire on first occurrence per host per day, then raise the threshold only after baselining. Allow-list login scripts, configuration management runs, and vulnerability scanners by parent image and service account, not by command name alone. Expect false positives from helpdesk troubleshooting scripts and remote support tools.
Windows identity queries outside admin context
On Windows, flag identity queries such as the current user or group membership lookups when they run from a non-administrative token, from a process not signed by the operating system or your software distribution, or from a user who has never run them before. Command execution and OS API execution telemetry both matter here, because an identity lookup can be made through a native API without starting a new process. Correlate the query with logon type and session age to separate a freshly phished user from a long-running service. Allow-list monitoring agents, endpoint protection, inventory collectors, and login scripts by hash and signer. Expect noise from IT support sessions, software deployment tools, and users who open diagnostic consoles.
Linux and macOS queries from service accounts
Alert when identity commands on Linux or macOS are run by web server, database, or application service accounts, since these accounts rarely have a reason to ask who they are. Process creation telemetry with the parent chain and user context is the key check, and a short lookback window helps show whether a web request preceded the command. Start with a threshold of any occurrence from a service account, then tune down to repeated occurrences within a short window if the first rule is too noisy. Allow-list health checks, package managers, and configuration management agents by exact parent and command pattern. Expect false positives from application startup routines and deployment hooks that read the current user to set file ownership.
Privileged session queries on network devices
On network devices, alert when privileged user or session queries come from management addresses outside the approved jump host or administration subnet, or when several privileged sessions are listed in a short period by an account that normally only changes interface settings. Command execution logs from the device or its syslog stream are the main source, and you should confirm which privileged show commands your platform logs before writing the rule. Set the threshold by counting session queries per source per hour against the admin team's normal pattern. Allow-list the network management platform, scheduled backup jobs, and monitoring pollers by source address and account. Expect false positives from monitoring tools that enumerate sessions and from engineers troubleshooting access.
Tuning and retiring allow-lists
Allow-lists decay as software and staff change, so treat each exception as a dated record with an owner. Review every exclusion whenever a monitoring agent, backup product, or login script is updated, and remove exclusions that no longer match a current parent image or source address. Track the alert volume per rule before and after each change so that a sudden drop does not hide a gap in coverage. Ask your detection engineering team to document the ATT&CK version each rule targets, because technique mappings can change between releases. Expect pressure to suppress noisy rules during incidents, so require a second reviewer for any broad exclusion.
How to validate that the T1033 detection fires
This sequence proves, in a private cyber range, that the T1033 System Owner/User Discovery detection produces a visible, correctly attributed alert in the SOC queue on each platform in scope. It also turns any gap into a tracked fix and a repeatable re-test.
Agree scope and rules of engagement
The SOC lead, the platform owners and the DeployOpen engagement lead agree in writing which hosts, accounts and platforms are in scope (Linux, macOS, Windows and network devices where applicable), which identity accounts the exercise may use, and what must never be touched in production. Stop conditions, a named contact for pausing the exercise, and the agreed cyber range boundary are recorded in the same document. The step is done when all parties have signed off the scope and rules in writing.
Define expected telemetry for each platform
For every platform in scope, the team writes down which telemetry should record identity discovery: process creation events, command execution logs, and OS API execution where the platform exposes it. The mapping references the ATT&CK version the detection targets and the data components named in the detection strategy, so each expected event has a source, a field and a log path. Gaps in logging coverage are noted here, before any activity runs. The step is done when a per-platform expectation sheet exists and the platform owners have confirmed that each log source is being collected.
Run a controlled identity discovery activity
A tester running under the agreed account performs benign, controlled identity-discovery activity on each in-scope platform, using the scripted plan and no custom tooling. The activity is limited to read-only checks of the current user context, so the team can compare what was done against what was logged. The tester records the start time, end time, host and account used for each run in the exercise log. The step is done when every planned run on every platform has a matching entry in that log.
Confirm the alert reached the SOC queue
The analyst on duty checks the Wazuh or Security Onion alert queue for alerts generated by each run, matching on host, time window and account. Each alert should show the detection rule ID, the telemetry source and the user context captured by the agent or sensor. The analyst confirms whether the alert was routed to the expected queue and whether it was triaged according to the runbook. The step is done when every planned run is either matched to an alert or logged as a missed detection.
Record evidence and document gaps
For each run, the exercise record captures the timestamps, host, user context, rule ID and alert reference, together with any gap found, such as a missing log source, a rule that did not fire, a wrong user attribution or a delayed alert. Each gap is classified by platform and root cause, and assigned an owner and a target re-test date agreed with the client. Evidence is stored in the client's own records system. The step is done when the evidence pack and gap register are complete and reviewed by the SOC lead.
Close gaps and re-test
Platform owners and detection engineers fix each gap, for example by enabling a missing log source, correcting a rule condition or adjusting the field mapping, and record the change in version control. The same controlled activity is then repeated on the affected platforms under the same scope and rules of engagement. A gap is only closed when the re-test produces the expected alert with the correct attribution. The step is done when every gap has either passed re-test or has an accepted risk decision signed by the client.
Keep the validation repeatable
The team stores the expectation sheet, the exercise script, the alert evidence and the gap register as a versioned package, so the same validation can be repeated after platform upgrades, rule changes or ATT&CK version updates. The client confirms whether the package should be re-run on a fixed schedule or after defined change events. The step is done when the package is stored, the owner is named, and the re-run triggers are written into the detection runbook.
Preventive controls that reduce T1033 exposure
T1033 System owner/user discovery is hard to block outright because the commands an attacker uses to learn the current user are also used by administrators and scripts. The controls below reduce how much an attacker can learn from identity queries, how quickly those queries are noticed, and where a foothold can reach. Each card maps to an ATT&CK mitigation and names what to confirm in your own environment.
Limit account sprawl with user account management
User Account Management (M1018) restricts who can create, modify and hold accounts on hosts and directories. When fewer accounts exist, and their group memberships are tightly bounded, the answer to "who am I and what can I reach" reveals less useful information. Confirm that shared, dormant and over-privileged accounts are reviewed on a schedule, that service accounts are inventoried, and that administrative group membership is documented. Ask your identity team which accounts would appear in a standard owner lookup on a sensitive host.
Harden baseline operating system configuration
Operating System Configuration (M1028) covers the settings that decide what a local or remote user can read, such as default session rights, shell access, and which directories expose account details. Tighten these settings through your configuration management tooling rather than by hand, and test changes against the applications that depend on them. Confirm that the baseline is version controlled, that drift is reported, and that unnecessary remote login methods are disabled on hosts that do not need them.
Audit identity queries and privilege use
Audit (M1047) is the mitigation that makes T1033 visible. Enabling the right operating system and identity audit policies lets your SIEM see process creation, command execution and directory lookups that reveal owner and user checks. Confirm that audit settings are applied on Linux, macOS and Windows endpoints, that logs are forwarded to a central store before local rotation, and that alerts on repeated identity checks from non-administrative sessions are tuned to your normal administrative workload.
Segment hosts that hold identity-sensitive data
Network Segmentation (M1030) limits what a compromised session can reach after it learns its own identity. Placing directory servers, jump hosts and management planes in restricted zones means that a user who discovers a low-privilege owner name still cannot query many systems. Confirm which subnets and VLANs permit administrative protocols, whether management traffic is isolated, and whether exceptions for vendor tools are documented and reviewed.
Block known-bad traffic and scans
Network Intrusion Prevention (M1031) can stop or alert on signatures and behaviors tied to remote enumeration that often accompanies owner checks on network devices and servers. Its value depends on rule currency and tuning, so confirm which rule sets cover your administrative protocols, who approves tuning changes, and whether blocking is enabled only where false positives have been measured. Pair detection content with the Suricata or Zeek sensors you already run so that inline and passive views agree.
Remove unused tools and features
Disable or Remove Feature or Program (M1042) reduces the number of built-in utilities an attacker can use to ask who is logged in or which account is active. Remove unused interpreters, legacy remote services and diagnostic packages from production images, and document the exceptions that operations teams still need. Confirm that image build pipelines enforce the removal list and that any remaining utility that reports identity is covered by Process Creation and Command Execution logging.
Triage steps when a T1033 alert fires
The first job when a T1033 alert fires is to decide whether the discovery activity is authorized administration or an intrusion, and to make that decision from evidence rather than from the alert text alone. Start with the originating process and its parent. Confirm which binary ran, which account launched it, and whether the parent is an expected management agent, an interactive shell from a known administrator session, a scheduled job, or something that should not be running a user lookup at all. On Windows, the same question is answered from process creation records and their parent chain. On Linux and macOS, check the shell history where it is retained, the terminal or SSH session that spawned the process, and the user context the command ran under, including whether a privilege change occurred just before it. Record the answer in the alert ticket before moving on.
Next, establish the session source and whether the same identity behaved normally elsewhere. Compare the account's recent logon sources, times and hosts against its baseline, and confirm with the owning team whether a change ticket, maintenance window or on-call task explains the activity. Then widen the view to the host. Look for other discovery techniques in the same window, such as network configuration, process, group or account enumeration, and for credential access signals, new authentication failures or successes, or unexpected file reads of credential stores. A single user lookup on an otherwise quiet host is usually weak evidence on its own. Several discovery steps followed by credential activity within a short period is a strong signal to escalate. Containment should preserve evidence: isolate the host at the network layer where your tooling allows, disable the account only if the activity cannot be explained, and capture volatile data and logs before any reboot or reimage. Escalate to incident response when the activity cannot be attributed to a known owner, when it appears alongside credential or lateral movement signals, or when the source is a host that should not be doing administrative enumeration. Document each decision with timestamps, the evidence reviewed, the people consulted and the final classification, so the post-incident review can reconstruct the reasoning and tune the detection rule.
Rehearsing T1033 detection in a private cyber range
On Linux and macOS endpoints, T1033 activity typically shows up as short-lived process creation events and command execution records tied to a user session. A private range for this environment usually contains a small set of Linux and macOS hosts enrolled in the monitoring stack, a central log pipeline, and a set of standard user and administrator accounts that mirror the client's identity model. The range should also include a simulated interactive session path, such as an SSH login, so responders can see how session context is recorded. Injects are scripted sequences of user-context queries run by an authorized operator, spaced over time and across several hosts, so the blue team must correlate them rather than react to one event.
- Range topology: Two or three endpoints per operating system, forwarding process and command telemetry to Wazuh or a comparable collector, with a Security Onion or Zeek sensor on the same segment.
- Injects: Repeated user-context enumeration from one account across several hosts, plus one inject from a service account that should not be interactive.
- Good detection: An alert fires within the agreed detection window, is enriched with the host, the parent process and the account, and is triaged under the agreed severity rules.
- Good response: The analyst confirms the session, pivots to the account history and decides whether to contain the session under the agreed playbook.
- Recording: Each exercise records detection timestamps, analyst decisions and gaps in the rule set for later tuning.
Confirm with your team which Linux and macOS endpoint types and logging agents are in scope, because telemetry coverage differs by distribution and by macOS version.
On Windows endpoints, T1033 detection depends on process creation telemetry with command line capture, along with OS API execution records where the endpoint agent provides them. A private range for Windows usually includes domain-joined workstations and a server, an Active Directory identity source that mirrors production group structure, and the same log pipeline used for other environments. Injects should be run by an authorized operator under a named test account, so that the blue team can separate expected administrative activity from suspicious use. The range should also include a noisy baseline of normal administration so that analysts practice filtering rather than assuming every event is hostile.
- Range topology: Domain controller, two workstations and one member server, with Sysmon or an equivalent endpoint agent and Windows event forwarding into Wazuh.
- Injects: Ownership and identity queries from a standard user account on one workstation, followed by the same queries from an account with elevated rights on the server.
- Good detection: A detection rule fires on the expected process and command pattern, the alert carries the account and host context, and the analyst reaches a triage decision inside the agreed timeline.
- Good response: The responder checks logon context for the account, reviews recent authentication events, and follows the agreed containment steps without disrupting the baseline administration.
- Tuning: Record every false positive from the baseline and document the exception logic before the next exercise.
Confirm which endpoint agent, audit policy and event forwarding configuration the client already runs, because detection quality depends on what is actually logged.
On network devices such as routers, switches and firewalls, T1033 activity is less about process telemetry and more about administrative sessions, command auditing and the syslog or API records that the device emits. A private range for this environment usually includes a representative device from each vendor family in use, a management network segment, a syslog collector, and a TACACS or RADIUS style administrative authentication source if the client uses one. Because many devices log administrative commands at different levels of detail, the range is the place to find out which events the client can actually see. Injects should be scheduled with the network operations team so that changes made during the exercise are reversible and the change window is recorded.
- Range topology: One management plane per device class, a dedicated syslog path to the collector, and a Zeek or Suricata sensor on the management segment where traffic is visible.
- Injects: Read-only status and identity queries issued from an administrative account on a management host, followed by a query from an account outside the normal administrator group.
- Good detection: The device audit record reaches the collector, a rule matches the administrative session and command pattern, and the alert is enriched with the device, the session source and the account.
- Good response: The analyst verifies the source address against the change calendar, checks authentication logs, and follows the agreed playbook for revoking a session or raising a change ticket.
- Gap review: Note every device class where the expected command event never reached the collector, since that gap is the most useful outcome of the rehearsal.
Confirm with the vendor documentation for each device model which administrative events are logged and at what level, because logging options vary between firmware releases.
Questions SOC leads ask about detecting T1033
How does T1033 System Owner/User Discovery differ from the other discovery techniques in this set?
T1033 focuses on identifying which user is logged in or which account owns the current session on a host, while most sibling techniques enumerate something else, such as accounts and groups (T1087), processes (T1057) or network connections (T1049). The practical difference is the telemetry: T1033 detections lean on Process Creation and Command Execution events that show identity-lookup utilities being run, plus OS API Execution on Windows, rather than on file or network content. Because a single identity check is common in administration scripts, the signal is weak on its own. Read T1033 alongside T1087 and T1082 so you can see when a host is being profiled in sequence, which is usually the stronger indicator.
Are Sigma rules enough to detect T1033 across Linux, macOS, Windows and network devices?
Sigma rules are a good starting point for Linux, macOS and Windows process and command events, but they are not sufficient on their own. Sigma covers the log sources it has a backend for, so you still need to confirm that your SIEM or Wazuh pipeline ingests the relevant command and process telemetry on each platform. Network devices need a separate check: confirm which syslog or AAA accounting records your vendor exposes for administrative commands, because the same rule logic may not apply. Validate every rule in a private cyber range against the ATT&CK version you target, currently v20.0, and record which platform each rule was tested on.
How do I reduce false positives from admin and monitoring tools that check the current user?
Most noise comes from configuration management, backup agents, endpoint tooling and health checks that run identity lookups on a schedule. Start by building an allowlist keyed on parent process, service account, host group and execution path, not on the command name alone, since attackers can use the same binaries. Review the top command lines over a representative period, then scope exceptions to specific hosts and accounts so the exception does not cover the whole fleet. Keep a change record for every exception so that a later review can see who approved it and why. Expect this tuning to be iterative and to recur whenever monitoring or automation tools change.
Which data sources should I confirm before relying on T1033 detection on network devices?
Confirm three things with your vendor and in your own environment: whether administrative command execution is logged, whether those logs are forwarded off the device, and whether the timestamps and user identity fields are consistent enough to correlate. Check AAA or TACACS accounting, syslog configuration and any session logging that records the commands an operator runs. Many devices log authentication but not every command, so a missing command record is a gap you must document, not assume away. Ask your network team to run a controlled administrative session in the cyber range and confirm that the expected record appears in your SIEM.
How should we handle ATT&CK version changes when maintaining T1033 detections?
Name the ATT&CK version in every detection mapping, and state that these mappings target Enterprise ATT&CK v20.0. Releases can rename, deprecate or revoke techniques and change detection content, so a mapping written against one version may need review after the next release. ATT&CK v18 replaced technique-level detections with detection strategies and analytics and revised data components, so older rule libraries may reference retired data source names. Check the MITRE updates pages when a new version ships, compare the technique and data component references against your rule inventory, and re-run the cyber range tests for any rule whose underlying data component changed.
How do I know whether our T1033 detection has coverage gaps?
A detection has a gap when it does not fire for a behavior it should catch, so measure coverage against controlled executions rather than against rule count. In a private cyber range, run a defined set of identity-lookup actions on each platform in scope, record the expected telemetry, and check whether the alert or hunt query fires within your normal triage window. Track the results per platform and per data source, and mark any platform where the required telemetry is absent as a gap. Repeat the exercise after each tuning change, since an exception can silently remove coverage. Keep the results as evidence that the control was tested, but do not treat a pass as proof that all variants are covered.
Can our own team run T1033 detection and rehearsal without an outside partner?
Yes, many teams can do this in-house if they already operate their SIEM, endpoint telemetry and a test environment. The work breaks into rule authoring, telemetry validation, tuning, cyber range rehearsal and documentation, and each has a cost in staff time that recurs as platforms and tools change. Costs rise with the number of platforms, the depth of network device logging and the need to produce audit-ready evidence. DeployOpen plans and implements self-hosted open-source platforms in your own infrastructure and runs cyber range exercises, typically under a fixed written scope, so you can ask for a quote that separates one-time build work from any ongoing retainer for tuning and testing.
How DeployOpen builds and maintains T1033 detections
DeployOpen starts each T1033 System owner/user discovery detection by mapping the technique to the ATT&CK version the client's program targets. For this page that is Enterprise ATT&CK 20.0, and the mapping is recorded against that version so the team can see which detection strategies, analytics and data components were used. The team then checks which data components the relevant detection strategies reference for each platform in scope, such as Process Creation (DC0032) and Command Execution (DC0064) on Linux, macOS and Windows. Because ATT&CK can rename, deprecate or revoke content between releases, the mapping is reviewed whenever the client moves to a newer version, and the reviewer confirms that the technique ID and its sub-techniques still match what the detection covers.
Next, the team implements the collectors and rules inside the client's own stack. That usually means confirming that the Wazuh agents or equivalent endpoint collectors on each platform actually record process creation and command execution events, that audit or process accounting is enabled where it is needed, and that the events reach the log pipeline with the fields the rules depend on. Rules are written as Sigma logic where possible and converted for the client's SIEM or Wazuh rule set. Each tuning decision, such as an allowlist for a monitoring agent or a backup job that legitimately queries identity context, is written down with the owner, the reason, the date and the condition under which the exception expires. The client's security team owns the final decision on every exception.
After any change to collectors, rules, log sources or the client's environment, DeployOpen reruns the detection in the private cyber range before the change is accepted, and it repeats the check on a set schedule under any retainer. The retest confirms that the expected events still arrive, that the rule still fires on the rehearsed behavior, and that the false positive rate on production-like telemetry has not moved in an unexpected direction. Results, including failed checks, are returned to the client with the ATT&CK version, the rule version and the tuning log. Clients should ask for this record as a standard deliverable in the written scope, and confirm with the team how long evidence is retained and in which system it is stored.
How DeployOpen rehearses and tunes ATT&CK detections
DeployOpen is a Chainscore Labs company that plans, implements and supports self-hosted open-source platforms inside the client's own infrastructure. For T1033 System owner/user discovery, the work starts with a written scope, builds detection content on open-source tooling, and tests it in a private cyber range before handover.
How we scope
- Agree in writing which Linux, macOS, network device and Windows hosts are in scope for T1033 telemetry.
- Confirm which Process Creation and Command Execution sources feed the SIEM for each platform.
- Record the ATT&CK version the detection mapping targets, so later releases can be compared against it.
How we build
- Deploy or configure the open-source collection components, such as Wazuh agents or Zeek and Suricata sensors, within the client's environment.
- Write detection logic in Sigma or the platform's native rule format, described in plain terms and reviewed against expected administrative activity.
- Document each rule's data components, known benign sources and the tuning thresholds agreed with the client's operations team.
How we hand over
- Deliver a test plan that replays benign and simulated T1033 activity in a private cyber range and records which alerts fired.
- Provide runbooks for triage, escalation and containment that match the client's incident response process.
- Hand over rule documentation, configuration files and test evidence in a form the client's compliance and audit teams can review.
How we support
- Engagements are fixed-scope, and ongoing tuning or re-testing can be added as a retainer.
- Review detection performance after ATT&CK releases, since techniques can be renamed, deprecated or revoked.
- Confirm with the client which support terms, response windows and upgrade paths apply before work begins.
