Entity boundaries
Primary vs. secondary
The first call Scope makes is splitting Subject’s 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. map into two tiers. The split is what makes investigation depth proportional to evidence rather than spending equal time on every identity in the graph.
Entities directly implicated by the alert. The user whose account fired the alert. The host that produced the telemetry. The service account that authenticated the action. The cloud resource the action targeted. Primary entities receive full investigation depth: every dimension, every available data source, the full historical window the threat type warrants.
Entities connected to the primary set but not directly named in the alert. Peer accounts that share a trust path. Systems the primary entities have access to. Parent services that issued credentials. Secondary entities receive baseline-comparison depth: are they behaving normally? They are investigated more thoroughly only if a primary investigation surfaces them.
Why this split matters
A SOC that treats every connected identity as primary spends six hours on one alert. A SOC that only investigates the named identity misses the Lateral Movement Adversary traversal from the initial-access host to other hosts inside the environment. Each hop expands the blast radius and adds new entities for Subject analysis. Often piggybacks on legitimate authentication, which is what makes it hard to detect. . The two-tier split is the methodology’s answer: deep on what the alert touched directly, baseline-only on what is connected, with explicit upgrade criteria.
Subject’s map may also carry a third ring: downstream systems the compromised identities can reach but that show no activity yet. Downstream entities do not get an investigation tier of their own; they get placed. Write them into the boundary as reachable, pin their logs to the infrastructure check, and name the signal that would promote them to secondary or primary. Leaving them off the boundary statement is how a federated platform or a connected CRM silently falls out of the case.
Primary entities by type
Primary entities require immediate, rigorous scrutiny. They are the foundation for everything Uncover will do, and capturing volatile or early-stage evidence depends on getting their scoping right at this moment. Four common categories cover most cases.
👤 User accounts
Often the initial access vector via credential theft or phishing. Once inside, attackers use the account to escalate and move laterally.
- Analyze authentication patterns: geolocation, time anomalies, login spikes.
- Review group membership changes, role escalations, MFA resets.
- Investigate use of remote execution tools (PowerShell, PsExec).
- Correlate access attempts with sensitive resource interactions.
💻 Endpoints
Execution platforms for malware, persistence mechanisms, and attacker tooling. Often hold key forensic artifacts that reveal intrusion methods.
- Examine process trees and parent-child anomalies.
- Inspect file system and registry paths for persistence (Startup, %APPDATA%).
- Check for unauthorized services, scheduled tasks, local admin creation.
- Analyze outbound traffic and DNS queries for C2 activity.
☁️ Cloud resources
Common target for privilege escalation, data access, and persistence via misconfigurations or stolen credentials. Abnormal API usage is often the first sign.
- Investigate IAM changes: user/role creation, key usage, permission escalation.
- Audit bucket and compute resource policies for unauthorized changes.
- Review CloudTrail, Azure Activity Logs, GCP audit logs for suspicious behavior.
- Monitor for exfiltration via storage, automation misuse, or unusual geographies.
⚙️ Applications
Compromised via vulnerabilities, misconfigured APIs, or weak authentication. Often act as pivot points to backend systems and data.
- Examine logs for injection attempts, RCE indicators, auth bypasses.
- Audit admin interface activity and role/permission changes.
- Review session tokens and API key behavior.
- Correlate frontend activity with backend database or storage access.
Tiering high-value entities
Not every primary entity carries the same weight. Three tiers of “high-value” entities deserve elevated attention from the moment they appear in the investigation.
Crown-jewel infrastructure
Domain controllers, cloud control planes (AWS Organizations management account), security vaults (HashiCorp Vault instances, Azure Key Vault). Compromise at this tier has organization-wide blast radius.
Revenue and operations systems
Finance applications (SAP, payment gateways), HR platforms (Workday, ADP), healthcare systems (Epic EHR, PACS servers). Direct impact on business operations and regulated data.
Administrative identities
Enterprise Admins group members, cloud IAM roles with iam:* permissions, database sa accounts. Capability to bypass controls and rewrite the security posture itself.
Scope evolution: the decision tree
Entity scope is not a one-time decision. It evolves as evidence develops. The evolution should follow a structured, documented pattern.
Compromised workstation accessed shared file drive \\fileserver\finance\
Incorporate fileserver into scope. Pull access logs, file modification history, share-permission changes.
User authenticated to VPN within 48 hours of compromise
Examine MFA logs and add VPN concentrators to scope. Validate session origin, device fingerprint, and concurrent-session behavior.
PowerShell remoting was enabled on the endpoint
Include WinRM configuration, the WinRM/Operational log, and PowerShell script-block and module logging (Event IDs 4104/4103) alongside 4688 process-creation events in scope. Look for cross-host script invocation.
Service account assumed a cloud role during the relevant window
Add the cloud role and all resources it can touch to scope. Review STS AssumeRole call patterns against the role’s normal usage.
Document each scope addition
Every entity added to scope after the initial decision should carry three lines of documentation:
- The evidence linking it in. e.g., “PowerShell script executed at 2024-03-14T15:32:27Z connecting to internal Jenkins server 10.45.67.89.”
- The risk assessment. e.g., “Jenkins server has pipeline access to production Kubernetes clusters; supply-chain compromise risk.”
- The required actions. e.g., “(1) Capture a memory image with an acquisition tool (LiME/AVML on Linux, WinPmem on Windows) for later analysis in Volatility 3, (2) review RBAC permissions, (3) validate build artifact SHA256 checksums.”
This documentation is what makes the scope expansion defensible later.
Secondary entities: three modeling techniques
Secondary entities are not in the alert. They get into scope through analysis of the operational topology and identity fabric. Three techniques surface them in a structured way.
🗺️ Relationship mapping
Document technical trust relationships: Active Directory two-way trusts, privileged service accounts with elevated access, AWS cross-account roles, Kubernetes service-account tokens. These reveal potential compromise paths the alert did not directly name.
🔑 Access modeling
Identify all identities with access during the relevant timeframe: contractors with SSO access, DevOps engineers with privileged cloud roles, recently-terminated employees with lingering credentials. The access model is the immediate-blast-radius estimate.
🔗 Dependency tracing
Analyze data flows and credential pathways: automated synchronization jobs, cached authentication tickets, cross-account access mechanisms, hardcoded API credentials. Dependencies turn a single compromised identity into a network of potentially-affected systems.
Prioritizing secondary entities during triage
Not every secondary entity deserves equal attention. Assess each one against proximity and likely adversary goals:
- Immediate-priority secondaries. Direct management, authentication, or automation ties to a compromised entity. (A service account that authenticates against the same identity provider. A peer in the same AD security group.)
- Mid-priority secondaries. Trust relationships that bridge to higher-value systems. (Cross-account IAM roles. Federated SAML trusts. Shared service principals.)
- Distal secondaries. Shared Infrastructure The systems, networks, and services that computing runs on. In triage the word points two directions: the organization's infrastructure is what alerts fire on, and attacker infrastructure is the set of C2 servers, domains, and staging hosts an adversary operates, which pivoting on indicators is meant to map. nodes or vendor-managed services. Assess based on exposure level, Credential Whatever the system accepts as proof of identity: a password, an API key, an OAuth token, a Kerberos ticket, an NTLM hash. Credentials are the highest-value loot in most intrusions; their theft is usually the pivot point. reuse, and control boundaries. Often watched, not investigated, unless a closer signal pulls them in.
Documenting this tiering keeps Uncover from spreading effort evenly across a long list and instead drives focused work where the methodology says the risk lives.
Containment and the entity scope
Entity scope informs Containment The incident-response phase between detection and eradication: isolate the affected hosts, revoke the compromised credentials, block the C2 destinations, freeze the situation so it stops getting worse while the investigation continues. decisions, and containment carries its own dependency risks. Isolating a host or disabling an account can break business operations as collateral.
🔌 Host isolation
Pulling a host from the network stops the compromise but interrupts any production work the host was doing. Validate dependencies before isolating: scheduled jobs, shared services, real-time workloads.
🔒 Account disable
Disabling a service account can break automation pipelines, sync jobs, or production deployments. Check what depends on the account before disabling; have a rollback plan.
🚪 Credential rotation
Rotating an API key invalidates every consumer of that key. For shared keys, the rotation needs a coordinated cutover across all consumers, or pre-staged replacement credentials.
📛 DNS/firewall block
Blocking a domain or IP range can stop C2 but may also block legitimate traffic if the indicator is reused infrastructure (cloud-CDN edge IPs, shared SaaS hosts). Validate uniqueness before blocking.
Key Takeaway
Entity scope is the difference between “investigate the 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. ” and “investigate the user, the three accounts that authenticate as them, the four systems those credentials access, and the two cloud roles those systems can assume.” The second is far more useful, and Scope is the phase that draws the lines, tiers them, and documents the evidence that justifies each addition.
Next up
Infrastructure boundaries
What the SOC can actually see. Network segments, cloud accounts, geography, retention, and tooling.
Read infrastructure