Entity types and analysis
The four entity types
Modern environments produce four broad categories of identities. Each one has its own normal patterns, its own ways of being abused, and its own analysis priorities.
👤 User accounts
Standard users, administrators, service accounts, external partners. Identity verification and access monitoring drive the analysis.
💻 Endpoints
Physical and virtual devices: workstations, servers, mobile, IoT, network infrastructure. The host is the address where activity actually happens.
⚙️ Applications and services
Business applications, dev tools, automation pipelines, cloud functions. Non-human identities with predictable but consequential behavior.
🌐 Network identifiers
IPs, domains, protocols, MAC addresses, certificates. Not identities in the strict sense, but the markers the system uses to route trust.
From identifier to identity
The alert rarely names a person. It names an IP, a hostname, or an account string, and the analyst resolves that identifier into an entity with a role and an owner before any of the analysis below applies. The pivot chain is mechanical:
- IP to host. Asset inventory or CMDB for static assignments; DHCP lease logs, the VPN concentrator, or the wireless controller for dynamic ones. Match the lease that covers the alert timestamp, not the current one, because the address may have been reassigned since.
- Host to account. Endpoint agent telemetry, workstation logon events, or VPN session logs show which account was interactive on the host during the window.
- Account to person and role. The identity provider resolves the account string to a directory record; the HR system resolves the record to a name, team, manager, and employment status.
Every hop can be wrong: DHCP reassigns, workstations are shared, accounts are borrowed. Note the confidence of each hop, because “the IP resolved to jsmith” quietly stacks three separate inferences.
User accounts
User The identity behind activity on a system: the account that authenticated, launched the process, or received the email. In triage the user field names an account, not necessarily a person; whether the legitimate owner was actually behind the activity is exactly the question stolen credentials raise. accounts produce the earliest and most actionable indicators of compromise. The analyst’s job is to evaluate the activity against the account’s expected pattern and lifecycle.
Creation and provisioning
Cross-reference account creation against HR onboarding and approved automation. Accounts that appear without a matching workflow are the classic backdoor pattern.
Modification events
Privilege grants, group memberships, role changes. Each is a moment where an attacker could be establishing or expanding their access.
Dormancy
Accounts inactive for 30+ days without being deprovisioned are a known soft target. They are credentials with no human watching them.
Termination
Off-boarded users should lose access across every integrated system within hours of HR’s record being updated. Orphaned credentials are how former employees become external attackers.
Password resets
Resets outside the normal rotation policy, especially from unexpected locations, can indicate social engineering or account-recovery abuse.
Subtypes of user accounts
Standard users
Predictable patterns tied to business hours and job function. Most volume, least permission.
Service accounts
Non-interactive by design. Highly predictable behavior. Interactive logins from a service account are a near-canonical compromise signal. These accounts straddle two categories: analyze the credential and its logons here, as an account, and analyze what it does inside a pipeline or application under Applications and services. A CI/CD service account gets both lenses.
Administrative accounts
High impact if abused. Should be used through privileged access management, not for routine work. Watch for admin accounts doing user-tier activities.
External accounts
Contractors, partners, vendor logins. Limited organizational visibility, broader attack surface. Compensating controls (time-bound access, narrow scope) are essential.
Shared accounts
Single credentials used by multiple people. Attribution becomes impossible. Treat any shared-account activity as a documentation risk before treating it as a security one.
Break-glass / emergency accounts
Reserved for cases where standard controls (PAM, MFA) are unavailable. Any usage must be logged, time-bound, and retroactively justified. Unscheduled activity should escalate immediately.
Endpoints
Each Endpoint A device that initiates network connections and runs user-facing software: laptop, desktop, server, phone, tablet. Endpoints are where most adversary tradecraft eventually shows up, which is why EDR exists. is a place where activity happens and a window into the broader environment.
Workstations
Standard user productivity machines. Compare current activity against the user’s historical pattern on this specific device.
Servers
Mostly service-account driven, predictable workloads, narrow user-interactive activity. Interactive logins on production servers deserve a closer look.
Mobile devices
Personal and managed. MDM telemetry, MAM data, EMM enrollment status. Off-network activity may be invisible to corporate logging.
IoT and OT
Limited instrumentation. Often legacy. Trust boundaries depend on segmentation rather than endpoint detection.
Cloud workloads
EC2 instances, Kubernetes pods, serverless functions. Short lifetimes mean baselines are statistical, not per-instance.
Network infrastructure
Routers, switches, firewalls. Compromise here is rare but high impact. Configuration drift is the most common signal.
Virtual desktops
VDI sessions, often accessed via thin clients or BYOD. Attribution is harder because sessions are ephemeral. Watch clipboard transfers, drive mapping, and process execution outside normal user hours.
Developer workstations
Run compilers, IDEs, repository tools. Broad internal access by design. Behavior that would alarm on a standard endpoint (scripting, sandbox bypass, dynamic loaders) is part of the job. Apply tighter baselines on the developer’s history rather than the environment-wide norm.
Applications and services
Applications and services are non-human identities that act on behalf of (or alongside) human users.
Why these often hide in plain sight
Applications and services often have broad, persistent access and very predictable behavior. That predictability is what makes anomalies stand out. A CI/CD service account that suddenly accesses a database it has never touched before is a louder signal than the same access from a human, precisely because the service account’s baseline is tight.
Business applications
ERP, HR, finance, CRM. Sensitive data, predictable workflows, regulatory exposure.
Development tools
Source control, CI/CD pipelines, package registries. Often have credentials that can deploy code into production.
System utilities
Backup agents, monitoring tools, configuration management. Run continuously, touch many systems, easy to overlook.
Cloud services
Managed cloud functions, container orchestration, service meshes. The identity boundary is often a cloud role rather than a credential.
OAuth / third-party applications
Apps granted delegated access to user or organizational data through a consent screen. They authenticate with tokens, so password resets and MFA never touch them. Inventory what has been consented and with which scopes; a newly registered app holding broad read scopes is the consent-grant abuse pattern, and revoking consent is the only control that removes the access.
AI agents and assistants
Copilots, RAG pipelines, and agentic automation hold delegated access to mail, documents, repos, and tickets, and act at machine speed. Baseline them like service accounts (tight scopes, predictable patterns) but treat their inputs as attack surface too: a prompt-injected assistant misusing its own legitimate token looks like an insider, not an intruder. The AI-assisted triage page covers both directions, the agent as analyst and the agent as subject.
Network identifiers
Network identifiers are how systems decide who is who when they cannot ask a person directly. Each identifier carries different forensic weight, and most of the analytical work is resolving them into the entities above (the pivot chain in From identifier to identity). Two habits carry most of the value: validate that traffic conforms to the protocol its port implies (SSH riding 443 is the classic bypass; port rarity means nothing), and treat every identifier as a pivot key into inventory, DHCP, and identity logs rather than as an answer by itself.
The identifier-by-identifier breakdown, eleven types with their forensic weight and classic abuse patterns, lives in the reference below. Skim it once, then return to it during live cases. It is a lookup table, not a lesson to memorize.
Key Takeaway
Each Entity Any discrete actor or object that evidence can attach to during an investigation: a user account, a host, a process, an IP address, a domain, a file. Triage decomposes an alert into its entities and asks what each one was doing; the same idea gives UEBA its E. type has its own pattern of normal and its own ways of being abused. Strong Subject analysis matches the analytical lens to the type. Treating a service account like a user (or a cloud role like a host) is how attackers go uninvestigated even when their activity is in the logs.
Network-identifier reference
A lookup table for triage: what each identifier is good for and the abuse pattern to check against it.
IP addresses
Source and destination locators for traffic. Internal IPs map to assets via the inventory; external IPs map to reputation via threat intelligence. Track geolocation, WHOIS ownership, and prior association with malware infrastructure.
Domain names
Higher-level naming abstraction often used by attackers to mask infrastructure (typosquatting, fast-flux, DGA). Assess domain age, registrar patterns, resolution frequency, and passive DNS history.
Protocols and ports
The signal is protocol/port mismatch, not port rarity: SSH riding port 443 or DNS on an arbitrary high port is the classic bypass pattern, and 443 is the most common port on the internet. Validate that the traffic actually conforms to the protocol the port implies.
MAC addresses
Lower in the stack but useful for tracking hardware across DHCP changes. MAC randomization, spoofing, or OUI changes over time can indicate NAC evasion or device impersonation.
BGP ASN
Group IPs by upstream provider. Anomalies include traffic from ASNs linked to bulletproof hosting, rapid ASN reassignment, or geolocation/ASN mismatches that suggest infrastructure churn.
FQDN patterns
Algorithmically generated subdomains, excessive subdomain depth, wildcard DNS abuse, or staged-malware delivery domains. Subdomain entropy is one of the strongest cheap signals.
SSL/TLS certificates
Examine issuer, validity period, key length, subject common name. Self-signed certs on production hosts, mismatched domains, or very short-lived certificates are classic C2 patterns.
DNS query behavior
Queries to external resolvers, uncommon record types (TXT, NULL), unusually high query rates, or high entropy in queried domains can signal covert data exfiltration via DNS.
JA3 / JA4 fingerprints
Hashes of TLS handshake parameters. Detect malicious clients or C2 infrastructure even when IPs and domains rotate. Flag fingerprints that deviate from enterprise baselines. Note that ClientHello extension randomization (Chrome since 2023) degraded JA3; JA4 is the successor, and modern feeds publish both.
URI / URL structures
Path depth, encoded parameters, file extensions. Flag unusual paths (e.g., /api/config.zip) or base64-encoded parameters that may indicate phishing kits, staged payloads, or HTTP-based tunneling.
API keys and tokens
Persistent identifiers granted to services. Track by issuance date, last-use date, scope, and the originator. Tokens that re-emerge after long silence often indicate compromise.
Next up
Behavioral framework
Pattern recognition, baseline development, anomaly detection. The toolkit for separating normal from suspicious at the Subject level.
Read behavioral framework