---
{
  "title": "System Owner/User Discovery",
  "summary": "System owner discovery identifies the users associated with a host.",
  "topic": "forensics",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1033"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1033: System Owner/User Discovery",
      "url": "https://attack.mitre.org/techniques/T1033"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

System owner discovery identifies the users associated with a host. This information can support targeting or decisions about what data to collect.


## An investigation example

An unknown process queries logged-in accounts shortly before accessing a particular user's working directories.

## Evidence to examine

Review identity queries, session information, process ancestry, and later user-specific file or application access.

## A common analytical pitfall

A support script may legitimately need the current user; the query must be assessed with its origin and subsequent use.

## Response considerations

Preserve the sequence and investigate whether the discovered identity influenced unauthorized access or collection.


## User context can shape the next action

Learning who uses a host can reveal its likely purpose and the information available there. Current sessions, process ownership, profile directories, and account-related records provide different views. A process running under one identity does not prove that the same person is physically present or directly controlling it. Service accounts and background activity complicate that inference.

Distinguish discovery from credential theft. Identifying a username or active session does not necessarily reveal a password or authentication token. The information may still help an intruder choose a target, but that is a different claim from proving access to the target's credentials. Keep the investigative language aligned with the observed behavior.

## A fictional targeted folder search

An academy's endpoint records show an unfamiliar process asking about logged-in users, then examining one user's working folder. Analysts compare process ancestry, file access, session context, and approved support activity. The sequence can support a hypothesis that the identity information influenced collection, but an ordinary support tool might produce part of the same pattern.

The useful question is why this process needed the information in this context. Consider its executable location, parent process, signer information where relevant, and later behavior. Do not create an alert that declares every current-user query malicious; routine software often uses the same system functions. Preserve the sequence so the relationship can be reviewed.

## Practice a bounded interpretation

Use fictional events showing a support utility and an unknown document-launched process both querying the current user. Compare what additional evidence would make one expected and the other concerning. Write a finding that identifies the observed query without claiming credential compromise. Then state what later access evidence would strengthen the hypothesis of user-targeted collection. This develops contextual reasoning rather than memorizing a command name as an indicator.

## Related concepts

- [[digital-forensics]]
- [[incident-timeline]]
- [[logs-and-telemetry]]
- [[os-credential-dumping]]
- [[command-and-scripting-interpreter]]
