Entity types and analysis

About 13 min read

On this page

S Pillar 02 of 05

Identity does not mean one thing. A user account is one kind of subject. A cloud VM is another. A service account that signs API calls on behalf of a deployment is a third. Each type carries its own risk profile and its own first checks.

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. The first checks on each card are the minimum pass; the sections below develop each type.

Sessions and tokens are identity objects profiled alongside the four types. A browser session, a refresh token, or a Kerberos ticket can act without its account authenticating again, so when the alert turns on one, profile it next to the account that owns it.

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:

1. 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. If the IP is your own egress NAT, proxy, or SASE address, it maps to many users: pivot on the proxy or ZTNA logs for the session instead. For cloud private IPs, resolve through the network interface records or VPC flow logs at the alert timestamp, because workloads recycle addresses in minutes.
2. Host to account. Endpoint agent telemetry, workstation logon events, or VPN session logs show which account was interactive on the host during the window.
3. 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.

Example: one alert, two entity types

An EDR alert fires on build-07, a Linux build server: curl fetched a script from pkg-mirror-cdn.example, a domain registered three days earlier, and piped it to a shell.

Endpoint lens first. build-07 is a server, so its baseline is narrow: the same compilers and the same package mirrors, every night. That domain is not one of them. Who was running on it at the time? No person: the process tree descends from the CI runner’s agent.

That moves the question to Applications and services. The runner executes jobs as svc-ci, so the first checks apply to the job, not only to the account. Which pipeline launched it? A job on a feature branch pushed forty minutes earlier. Who pushed that branch? A contractor account making its first push to this repository. Do the job’s calls match its peers’? No other build job has ever contacted that domain.

The endpoint lens alone says “a server ran curl.” The two lenses together say “an unfamiliar contributor changed what the pipeline runs,” which is the lead Scope and Uncover pick up.

---

User accounts

User 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 are where much of the actionable evidence of compromise collects, because almost every intrusion eventually acts through one, even when initial access came through an exploited edge device. The analyst’s job is to evaluate the activity against the account’s expected pattern and lifecycle.

Subtypes of user accounts

---

Endpoints

Each endpoint Endpoint A device that runs an operating system and applications and connects to the network: workstation, laptop, server, virtual machine, phone, tablet. Endpoints are where execution-based tradecraft (malware, scripts, hands-on-keyboard commands) shows up, which is why EDR exists. Identity, SaaS and cloud-control-plane attacks, and attacks on network appliances that cannot run EDR, may never touch one, so endpoint silence is not proof of absence. is a place where activity happens and a window into the broader environment.

---

Applications and services

Applications and services are non-human identities Non-Human Identity (NHI) An identity used by software rather than a person: service accounts, cloud roles and workload identities, API keys, OAuth applications, CI/CD tokens, AI agents. Non-human identities often outnumber people, hold standing privilege, skip MFA, and behave predictably, so one doing something interactive or new is a strong Subject signal. They are subjects in their own right. See Non-human identities and cloud roles. that act on behalf of (or alongside) human users. The cards below are the first pass. Non-human identities goes deeper: cloud roles and assumed-role sessions, workload identity federation, CI/CD tokens and AI agents, how to answer “who is behind this” when no person is, and how to baseline automation.

---

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: a common port proves nothing, and a rare port is only a weak hint on its own), 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 (ten 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.

Network-identifier reference

A lookup table for triage: what each identifier is good for and the abuse pattern to check against it.

Identifier	Good for	Abuse to check
IP addresses	Source and destination locators for traffic. Internal IPs map to assets via the inventory; external IPs map to reputation via threat intelligence.	Geolocation, WHOIS ownership, and prior association with malware infrastructure. A clean residential IP proves nothing on its own.
Domain names	A naming layer attackers often use to mask infrastructure.	Typosquatting, fast-flux, and algorithmically generated (DGA) domains. Assess domain age, registrar patterns, resolution frequency, and passive DNS history.
Protocols and ports	Checking that traffic is what its port claims.	The stronger signal is protocol/port mismatch, not port rarity alone: 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.
MAC addresses	Tying DHCP leases to a device within a segment.	Modern phones and laptops present a randomized per-network MAC by default (Android 10+, iOS 14+), so the address may not match the hardware MAC in asset inventory and its OUI tells you nothing. Randomization alone is normal. The signals are the same MAC seen on two ports at once, a corporate-asset MAC on an unmanaged port, or a known asset’s MAC whose posture or fingerprint does not match (NAC evasion or device impersonation).
BGP ASN	Grouping IPs by upstream provider.	Traffic from ASNs linked to bulletproof hosting, rapid ASN reassignment, or geolocation/ASN mismatches that suggest infrastructure churn.
FQDN patterns	Spotting generated or staging hostnames.	Algorithmically generated subdomains, excessive subdomain depth, wildcard DNS abuse, or staged-malware delivery domains. Subdomain entropy is a cheap first-pass filter, not a verdict: CDN and cloud hostnames (CloudFront’s d111111abcdef8.cloudfront.net, for example) are random by design, so suppress known provider zones and weigh entropy together with label length, query volume to a single parent zone, and domain age (see DNS query behavior below).
SSL/TLS certificates	Linking servers that share issuance patterns.	Examine issuer, issuance date, SANs, and key. Self-signed or default-template certificates (known C2 framework defaults), SANs that do not match the contacted domain, and a certificate issued hours before first contact for a newly registered domain are the useful signals. Short validity on its own is now normal: public TLS certificates have been capped at 200 days since March 2026, and Let’s Encrypt has offered 6-day certificates since January 2026. Pivot through Certificate Transparency logs (crt.sh) and JA4X/JARM server fingerprints.
DNS query behavior	Seeing covert channels that ride name resolution.	Queries to external resolvers, uncommon record types (TXT, NULL), unusually high query rates, or high entropy in queried names can signal data exfiltration or tunneling over DNS.
JA3 / JA4 fingerprints	Recognizing malicious clients or C2 infrastructure even when IPs and domains rotate.	Fingerprints that deviate from enterprise baselines. ClientHello extension randomization (Chrome since 2023) degraded JA3; JA4 is the successor, and modern feeds publish both.
URI / URL structures	Reading path depth, encoded parameters, and file extensions.	Unusual paths (for example /api/config.zip) or base64-encoded parameters that may indicate phishing kits, staged payloads, or HTTP-based tunneling.

---

Next up

Non-human identities

Service accounts, cloud roles, workload identities, OAuth apps, CI/CD tokens and AI agents: who can become each one, who is behind a session, and what normal looks like.

Read non-human identities